Instrument interface standards for interoperable ocean sensor networks

1

Instrument Interface Standards for Interoperable Ocean Sensor Networks

T.C. O’Reilly, K. Headley, D.R. Edgington, C. Rueda Monterey Bay Aquarium Research Institute

([email protected]) K. Lee, E. Song

National Institute of Standards and Technology ([email protected])

J. Zedlitz Christian Albrechts University at Kiel

([email protected]) J. del Rio, D. Toma, A. Manuel

Polytechnic University of Catalunya ([email protected])

E. Delory dBscale ([email protected]) C. Waldmann, University of Bremen

([email protected]) S. Fairgrieve

Northrop Grumman Corporation ([email protected])

L. Bermudez SURA ([email protected])

E. Bridger, P. Bogden GoMOOS ([email protected])

A. Amirault Compusult Ltd ([email protected])

Abstract— The utility and cost-effectiveness of instrument networks are enhanced by instrument interoperability. Today’s oceanographic instruments are characterized by very diverse non-standard software protocols and data formats. This diversity of protocols poses serious challenges to integration of large-scale sensor networks. Standard instrument protocols are now being developed to address these challenges. Some of these standards apply at the IP-network level and enable integration of existing “lower level” proprietary instrument protocols and software components. Other approaches are intended to be implemented by the instrument device itself. These native instrument protocol standards offer the possibility of more uniform and simpler system architectures. We compare these various approaches, describe how they can be combined with one another, and describe some prototypes that implement them.

I. INTRODUCTION Instrument interoperability is useful for several reasons and

is especially important in observing systems that contain many kinds of instruments [1]. We say that a set of instruments are interoperable with one another if the instruments can be operated through a standard protocol and if the instruments’ raw data can be processed through a standard set of tools (data interoperability). Interoperability simplifies the following:

• System integration and test: Operators do not necessarily need to know detailed manufacturer-specific protocols when instruments can be operated through a common protocol and their data can be automatically processed and checked with a common set of tools.

• Automated instrument and observatory resource management: A standard instrument protocol simplifies applications that manage instrument data sampling, system power, telemetry, positional tracking, etc.

• Data processing: Procedures that process raw data, transform data to a standard format, and archive and “visualize” data are simpler to design and implement when the

raw data are in a standard format or described in a standard way.

System integration, test, and resource management are particularly important to individual observatory “owners” who must operate and maintain the observatory. Data interoperability is more globally important, as users from many organizations and disciplines may wish to access and process data from multiple observatories.

Instrument interoperability can be achieved through standards that are enforced at various layers within an observing system. Figure 1 schematically represents some of those layers in a modern observing system. In this view, physical instruments are considered to be at the lowest layer in the observatory protocol stack. Instruments communicate with an observatory through a communications port on an observatory “host” computer. Most of today’s digital oceanographic instruments have a RS-232 or RS-485 interface. Beyond these electrical signaling interfaces, the current market is characterized by very diverse proprietary command protocols and metadata and data formats, with virtually no standardization between manufacturers. We refer to the protocol built in to the instrument as “native instrument protocol.”

The observatory protocol is above the instrument protocol layer. Observatory protocols include “instrument driver” interfaces that enable observatory components to interact with instruments in a uniform way. The drivers map between the observatory protocol and specific native instrument protocols. In addition, the observatory will include descriptions of each instrument (e.g. , as “configuration files”) that enable drivers and other components to interact with specific instruments and their data. Observatory applications (Figure 1) can access instruments and otherwise manage the observatory, using the observatory protocols.

Individual observatory driver interfaces and instrument description formats are often not “standard” beyond the particular observatory. Use of more widely-accepted standards

1-4244-2523-5/09/$20.00 ©2009 IEEE

2

Figure 1. Interoperable instrument protocol layers

within the individual observatory layer poses some challenges. Many observatories have invested years of effort into instrument driver development and other software infrastructure and it may not be desirable or financially practical to replace them with more standard components. A more incremental redesign of these existing systems may be more realistic. As we describe below, existing observatories can add relatively “lightweight” software layers that integrate them with instrument and Internet standards, while preserving most of the internal observatory infrastructure.

Figure 1 shows standard Internet protocols as the topmost layer. This layer allows applications to remotely access instruments and their data via the Internet through standard interfaces and metadata formats from any observatory that implements the standard interface(s). As we describe below, it is possible to access instruments through an Internet standard interface, even though the physical instrument itself does not adhere to any standard interface.

Internet access also poses some interesting security and scalability challenges. Internet standards such as Sensor Web Enablement offer methods to actually configure and control instruments via the Internet, but in many or perhaps most cases observatories need a means to restrict these operations to authorized users. In addition, an Internet interface raises the possibility of simultaneous access by very large numbers of users, while in some cases the actual instruments are available only via low-bandwidth or intermittent communications links. Observing system designs must account for bandwidth and power restrictions within the observatory, e.g., through the use of instrument “proxies.”

In the following sections we examine some current interoperability standards at both the Internet and instrument layers.

II. STANDARD INTERNET PROTOCOLS

A. IEEE 1451 The Institute of Electrical and Electronics Engineers (IEEE)

1451 smart transducer interface protocols define a set of network-independent communication interfaces to connect smart transducers to microprocessors, instrumentation systems, and control/field networks [2]. A smart transducer is the integration of an analog or digital sensor or actuator element, a processing unit, and a communication interface [3]. An IEEE 1451 smart transducer provides functions beyond those necessary for generating a correct representation of a sensed or controlled quantity. This additional functionality typically simplifies the integration of the transducer into applications in a networked environment [4]. Figure 2 shows an IEEE 1451 smart transducer [5], which consists of a Transducer Interface Module (TIM), a Network Capable Application Processor (NCAP), and an interface between the TIM and NCAP. The NCAP provides a gateway function between the TIMs and a user network. The TIM corresponds to an “instrument” and consists of elements such as transducers (sensors or actuators), signal conditioner, analog-to-digital and/or digital-to-analog converter, an interface, and a set of Transducer Electronic Data Sheets (TEDS). The complexity of a TIM ranges from a single sensor or actuator to an instrument containing many transducers. The NCAP communicates with the TIM through a physical digital interface, which could be wired or wireless.

Network

IEEE 1451.0

IEEE 1451.X

Network Capable

Application Processor

(NCAP)

IEEE 1451.1

IEEE 1451.0HTTP

Protocol

Smart Transducer

Web Services

IEEE 1451.21451.31451.5

p1451.7

Sensor(s)IEEE 1451.4Transducer(s)

Actuator(s)

Transducer Interface Module

(TIM)

1451.X PHY TEDS

IEEE 1451.X

IEEE 1451.0

Signal Conditioning & Data Conversion

1451.0 TEDS

IEEE 1451.X

Physical Interface

Mixed-Mode InterfaceM

MI

IEEE 1451Smart

Transducer

Figure 2. IEEE 1451 Smart Transducer

There are three possible network interfaces that can be used to access TIM sensors and actuators from a network. These

3

interfaces are defined in the IEEE 1451.1-1999 standard [6], the IEEE 1451.0-2007 Hyper Text Transfer Protocol (HTTP) [3], and the proposed Smart Transducer Web Services (STWS) [7][8]. As shown in Figure 2, the IEEE 1451.X physical interfaces between the NCAP and TIM include the point-to-point serial interface defined in the IEEE Std. 1451.2-1997 [9] and its revision being updated in the IEEE P1451.2 Working Group. We discuss this native instrument protocol below.

B. IEEE 1451.0 The IEEE 1451.0 standard defines a common set of

commands and functions to access sensors and actuators connected in various physical configurations, such as point-to-point, multi-drop, wired and wireless, to meet various application needs. This set of functions, independent of the physical communications media, includes the basic functions to read and write to the transducers, read and write TEDS, and send configuration, control, and operation commands to the TIM. The functionality makes it easy to add other proposed IEEE 1451.X physical layers to the family in the future. One of the main goals of the IEEE 1451.0 standard is to help achieve data interoperability for the IEEE 1451 family when multiple wired and wireless sensor networks are connected together [4].

The IEEE 1451.0 HTTP protocol focuses mainly on accessing transducer data and TEDS through the HTTP 1.1 protocol. Users can send a HTTP request to a HTTP server on a NCAP and receive a response from the server. The server response can be either in Extended Markup Language (XML), Hyper Text Markup Language (HTML), or Text format. Thus the IEEE 1451.0 HTTP protocol provides a simple Web access to IEEE 1451 smart transducers. Protocol methods that retrieve sensor data records return the data in standard format, thereby achieving data interoperability.

C. Transducer Electronic Data Sheet (TEDS) The transducer electronic data sheet (“TEDS”) is a key

concept of IEEE 1451. A TEDS describes characteristics and capabilities of components such as transducers, TIMs, and communications links in a standard way. Applications can retrieve the TEDS through the IEEE 1451 protocols to dynamically discover instruments, sensors, and actuators as well as other system characteristics.

IEEE 1451.0 defines the TEDS formats for the family of IEEE 1451 standards. The IEEE 1451.0 TEDS are classified into mandatory and optional TEDS. The mandatory TEDS include Meta TEDS, Transducer Channel TEDS, PHY TEDS, and User Transducer Name TEDS. The optional TEDS include Calibration TEDS, Frequency Response TEDS, Transfer Function TEDS, Manufacturer-defined TEDS, End User Application-specific TEDS, and Text-based TEDS, which include Meta ID TEDS, Transducer Channel ID TEDS, Calibration ID TEDS, Command TEDS, Location and Title TEDS, and Geo-location TEDS

D. Smart Tranducer Web Service (STWS) The STWS consists of a set of web services for accessing

IEEE 1451 smart transducers [7][8]. The STWS described in Web Service Definition Language (WSDL) is based on

service-oriented architecture (SOA) and the IEEE 1451.0 transducer services. The STWS WSDL specification is divided into six major elements: definitions, types, messages, portType, binding, and service. The STWS provides a unified Web service for IEEE 1451 smart transducers. The STWS component could reside in a separate computer to serve an IEEE 1451 smart transducer as shown in section (a) of Figure 3. It can reside in an NCAP to serve an IEEE 1451-based sensor network as shown in section (b) of Figure 3. The STWS component could also reside in an integrated IEEE 1451 smart transducer as shown in section (c) of Figure 3 [10]. The STWS provides a standard way to achieve interoperability of IEEE 1451 smart transducers with sensor applications.

Figure 3. STWS unified web service for IEEE 1451 smart transducers

E. OGC Sensor Web Enablement A sensor web (Figure 4) refers to Web-accessible sensor

networks and archived sensor data that can be discovered and accessed using standard protocols and Application Program Interfaces (APIs) [11].

Figure 4. Sensor web (courtesy of OGC)

4

The Open Geospatial Consortium - Sensor Web Enablement (OGC-SWE) group is building a framework of open standards to exploit Web-connected sensors and sensor systems, such as flood gauges, air pollution monitors, stress gauges on bridges, satellite-borne earth imaging devices, oceanographic instruments, and other sensors and sensor systems [11]. The OGC-SWE initiative focuses on developing a set of standards to enable the discovery, exchange, and processing of sensor observations and tasking of sensor systems. The OGC-SWE members have developed and tested the following specifications [12]: • Observations and Measurements (O&M) – Standard

conceptual model and XML schema to encode observations and measurements. O&M defines an “observation” as an event whose result is an estimate of the value of some property of a feature of interest, obtained using a specified procedure. A sensor, channel, or systems of sensors could all be treated as a procedure. Data interoperability between instruments can be achieved with the O&M standard.

• Sensor Model Language (SensorML) – Standard conceptual model and XML schema to describe sensors, systems, and processes; provides information needed for discovery of sensors, location of sensor observations, configuration of sensor networks, processing of low-level sensor observations, and listing of ”task-able” processes

• Transducer Markup Language (TransducerML or TML) – Conceptual model and XML schema to describe transducers and real-time streaming of data to and from sensor systems.

• Sensor Observation Service (SOS) - Standard web service interface for requesting, registering, filtering, and retrieving observations and sensor system information. SOS is the intermediary between a client and an observation repository or near real-time sensor channel.

• Sensor Planning Service (SPS) – Standard web service interface for requesting user-driven acquisitions and observations. SPS is the intermediary between a client and a sensor collection management environment.

• Sensor Alert Service (SAS) – Standard web service interface for publishing and subscribing to alerts from sensors.

• Web Notification Service (WNS) – Standard web service interface for asynchronous delivery of messages or alerts from SAS and SPS web services and other elements of service workflows.

F. SensorML SensorML is a key component of SWE, providing

standard sensor models and an XML encoding to describe any process associated with a sensor. All processes define their inputs, outputs, parameters, methods, and relevant metadata. SensorML models detectors and sensors as processes that convert real phenomena to data. It provides a functional model of a sensor system, rather than a detailed description of its

hardware. It also treats sensor systems and the system’s components (e.g., sensors, actuators, platforms, etc.) as processes. Thus, each component can be included as a part of one or more process chains that can either describe the lineage of the observations or provide a process for geo-locating and processing the observations to higher level information. In addition, SensorML provides additional metadata that are useful for enabling discovery, identifying system constraints, providing contacts and references, and describing “task-able” properties, interfaces, and physical properties [14].

G. Integration of IEEE 1451 and OGC-SWE While the IEEE 1451 suite of standards deals with sensor

metadata and sensor data from physical sensors to the network, OGC-SWE brings sensor information into Web applications. Applying both sets of standards will ultimately achieve the ease of use of sensors and ability to transfer sensor information from physical sensors to applications in a seamless manner using consensus-based standards [15]. The question is how to apply or integrate IEEE 1451 and OGC-SWE to achieve instrument interoperability. The STWS is the proposed method to seamlessly integrate IEEE 1451 standards with the OGC-SWE standards and other sensor applications. The OGC Web Services 5 interoperability exercise focused on integration of SWE interfaces and encodings into workflows to demonstrate the ability of SWE specifications to support operational needs. OWS-5’s “Team-1451” implemented and demonstrated the integration of IEEE 1451-based smart sensors and the SWE Web Services through the STWS [10][12][34].

III. STANDARD NATIVE INSTRUMENT PROTOCOLS Standard protocols and formats can also be implemented

“natively” within the instrument firmware. Even a minimal standard that provides a unique identifier for every compliant instrument enables automated integration of instrument driver and metadata when the instrument is plugged into an observatory. More comprehensive instrument standards can completely specify how to interact with an instrument, retrieve its data, etc., and hence offer the potential to eliminate external drivers entirely.

IEEE 1451.2 defines a comprehensive standard native instrument interface including operations to configure and calibrate the device, trigger data acquisition, retrieve the instrument’s TEDS, and so on. Thus instruments that implement IEEE 1451.2 do not require an external driver, since a standard protocol to interact with the instrument is implemented by the device itself. The IEEE 1451.2 standard is still evolving. The original 1997 specification defined a digital ten-wire parallel interface to connect transducers in a Smart Transducer Interface Module (STIM) to a microprocessor NCAP [9]. In its current state, IEEE 1451.2-1997 is not compatible with the IEEE 1451.0 standard. The IEEE p1451.2 working group is currently revising the standard to be compatible with IEEE 1451.0-2007. In addition, other popular interfaces, such as RS-232, Universal Asynchronous Receiver/Transmitter (UART), Serial Peripheral Interface (SPI), and Universal Serial Bus (USB) are being considered for

5

inclusion in the revised IEEE p1451.2 standard. This revision will be particularly relevant to today’s oceanographic instruments, the majority of which have a RS-232 digital interface, often with only three to five wires. (Most underwater instruments limit the number of wires to reduce the cost, weight and complexity of cables, connectors, and housings.)

Monterey Bay Aquarium Research Institute (MBARI) PUCK is a somewhat minimal native protocol for RS-232 and RS-485 devices and enables “self-identifying” instruments that can be automatically integrated into an observing system [16]. PUCK accomplishes this by physically associating information needed to configure and operate the instrument with the device itself and providing a standard interface to retrieve that information. When the instrument is plugged in, the observatory retrieves the information through the standard PUCK protocol and automatically reconfigures itself to accommodate the instrument and its data stream. This automated “plug and work” functionality eliminates error-prone manual configuration steps. PUCK protocol augments but does not replace the existing manufacturer-defined native instrument protocol. Thus a PUCK-enabled instrument recognizes both the PUCK protocol and the manufacturer-defined protocol. The PUCK protocol specifies a 96-byte “instrument data sheet” that can be retrieved from the device. The data sheet includes manufacturer, model and version codes, instrument name, and a universally unique serial number (UUID) for every instrument. Observatories can use the UUID as a key into an externally-defined database that could contain a more complete instrument description (e.g., an IEEE 1451 TEDS or SensorML document) as well as driver code for the instrument. In addition, PUCK specifies optional “payload” storage within the instrument itself and a protocol to write and retrieve payload contents. Thus metadata and driver code can be stored within the instrument before deployment and later retrieved directly from the instrument rather than from an external database. PUCK does not place any restriction on payload content or format. As of this writing, four manufacturers have implemented PUCK in their instrument firmware and report an average of 2-3 weeks engineering effort to do so. PUCK protocol requires only three wires (RX, TX, and GND). PUCK will soon be submitted to the Open Geospatial Consortium for consideration as an OGC standard.

The comprehensive IEEE 1451.2 approach and minimal MBARI PUCK approach each present challenges and drawbacks. Because it is comprehensive the IEEE 1451.2 specification is quite complex, requires detailed understanding and it is likely that most manufacturers will have to start “from scratch” when implementing it in their instrument’s firmware. Moreover IEEE 1451.2 protocol is still evolving and it is not yet certain when a stable version compatible with RS-232 instruments will be available. While MBARI PUCK is relatively straightforward and cheap to implement, it is not useful on its own and external instrument drivers are still required. Thus PUCK protocol by itself does not provide instrument interoperability. Moreover as upper-level protocols evolve, PUCK payloads that implement those protocols must be kept up to date.

IV. INTEROPERABLE TEST-BED

A. Description of Interoperable Test-Bed

We have developed an interoperable instrument test-bed in collaboration with OGC and some members of the Sensor Standards Harmonization Working Group (SSHWG) led by the National Institute of Standards and Technology (NIST) [17]. The goal of this effort is to demonstrate how IEEE 1451, OGC Sensor Web Enablement, and MBARI PUCK protocols can be integrated to rapidly acquire, fuse, and assess data from a diverse set of instruments and individual observatories. The test-bed was originally demonstrated at the 2008 Ocean Innovations Interoperability Workshop [18] and has since been refined and most recently demonstrated at the 2009 NSF Ocean Observing Initiative Instrumentation Workshop [19].

The test-bed currently integrates individual observatories at four different institutions in the USA and Europe into a single sensor network. Three of these observatories are associated with the European Seafloor Observatory Network (ESONET) [20] and are located in Spain and Germany. The fourth is located at the Monterey Bay Aquarium Research Institute (MBARI) in California USA. Each individual observatory contains multiple instruments and independently-developed

Figure 5. Interoperable instrument test-bed architecture

software components, some of which do not conform to recognized standards. However, team-members at each observatory have implemented IEEE 1451 “adapter” software that maps between IEEE 1451.0 protocol and their observatory protocols. Thus Internet applications that recognize IEEE 1451.0 can access the observatories’ instruments through an IEEE 1451.0 server associated with each observatory (lower left corner of Figure 5).

6

TABLE I. TEST-BED OBSERVATORIES AND INSTRUMENTS

Observatory Instrument UPC-SARTI

(Vilanova, Spain) SBE37-SM CTD

University of Bremen

(Germany)

Sea and Sun CTD SBE37-SM CTD

Christian Albrechts

University at Kiel (Germany)

Sea and Sun CTD IFM GeoMar meteorological

instruments

MBARI (USA) SBE37-SM (w/PUCK) RBR XR420 CTD (w/PUCK) WETLabs Triplet fluorometer

(w/PUCK) ASIMET wind sensor

One such application is the STWS, which provides a bridge between OGC-SWE protocol and IEEE 1451.0. Thus OGC-SWE components such as a Sensor Observation Service (SOS) can access the individual observatory instruments through the STWS. The current test-bed utilizes just a subset of IEEE 1451.0, including methods to discover TIMs on each NCAP, retrieve various TEDS, get the geo-location of each TIM, and acquire data from each TIM channel.

Figure 6. UPC-SARTI observatory architecture

Figure 6 schematically depicts the UPC-SARTI observatory which is a prototype for the OBSEA cable-to-shore observatory to be deployed in the western Mediterranean Sea in 2010 [21][22]. The UPC-SARTI NCAP executes the IEEE 1451.0 server and instrument drivers. One or more RS-232 instruments are plugged into the NCAP. The server and instrument drivers treat the attached instruments as IEEE 1451 TIMs, each TIM containing one or more transducer channels. The NCAP is implemented by a very low-power yet capable Imsys Technologies SNAP module [23] and the server and drivers are implemented in Java J2ME. The server can be reconfigured as instruments are installed or removed from the NCAP. For demonstration purposes, the observatory’s Seabird CTD sensor

can be installed in a hyperbaric chamber to simulate varying water depth. The basic UPC-SARTI design is heavily influenced by IEEE 1451.

In contrast the MBARI observatory provides an example of a “legacy” system. Over the past several years MBARI has developed and deployed observatory middleware called “SIAM” for use on its moored observatories (MOOS) as well as the MARS cable-to-shore observatory [16]. For each physical instrument in the observatory, SIAM provides an instrument driver that presents a generic “service” interface to clients on a TCP/IP network. Similar in design philosophy to IEEE 1451, the SIAM instrument service interface comprehensively defines how clients configure, control, and retrieve data from the associated instrument. Clients request these operations through the generic interface, without having to know the native instrument serial protocol, as those details are “hidden” by the SIAM instrument drivers. SIAM also recognizes MBARI PUCK protocol and automatically retrieves driver code and instrument metadata from an instrument that implements PUCK, thus achieving “plug and work” behavior. SIAM has proven very useful and extensible over the past several years. The interoperability test-bed thus presents an excellent opportunity to integrate a “legacy” system (SIAM) with standard interfaces (IEEE 1451, OGC-SWE).

In our test-bed the SIAM software executes on a MBARI Mooring Controller (MMC), which implements an IEEE 1451 NCAP (Figure 7). Instruments are plugged into serial ports on the MMC [24]. The MBARI IEEE 1451.0 server runs on a workstation host on the MBARI network and communicates with the SIAM instrument services via Java Remote Method Invocation (RMI).

Figure 7. MBARI SIAM observatory adapted to IEEE 1451.0

To integrate SIAM with IEEE 1451.0, the MBARI developers implemented an “adapter” component that maps between IEEE 1451.0 requests coming through the server and methods in the SIAM service interface (Figure 7). Given the similar design philosophy between SIAM and IEEE 1451.0, the mapping between the two protocols is straightforward. Thus when the IEEE 1451.0 server receives a client request, it issues appropriate method calls to the SIAM instrument service(s),

7

transforms the values returned by the instrument service to IEEE 1451.0 format, and returns the values to the IEEE 1451.0 client. The MBARI developers also slightly extended the SIAM instrument service classes to incorporate the IEEE 1451 “transducer” concept.

SIAM recognizes PUCK protocol and retrieves the payload of a PUCK-enabled instrument when the device is plugged in. For the test-bed, metadata needed by the various IEEE 1451 TEDS are stored in the instruments’ PUCK payload, automatically retrieved by SIAM when the instrument is installed, and transferred to IEEE 1451.0 clients (including the STWS) on request. Thus metadata retrieved from the instrument itself through PUCK protocol is propagated across the sensor web.

B. Sensor Applications Any sensor application that retrieves instrument data and

metadata through the SWE SOS interface can access any of the test-bed instruments regardless of location, via the Northrop Grumann SOS (which in turn accesses the test-bed observatories through the STWS) (note the Compusult and OOSTethys SOS clients in Figure 5). The OOSTethys development team modified their SOS client such that it

Figure 8. OOSTethys SOS client and MBARI visualizer

can also display data and metadata retrieved directly through the observatories’ IEEE 1451.0 servers by the “MBARI 1451 visualizer” component shown in the lower right of Figure 5. In our test-bed, data retrieval through the IEEE 1451.0 interface is currently faster and more efficient than retrieval through the SOS. As shown in Figure 8, the OOSTethys SOS client presents the user with a Google Maps interface, displaying the location of instruments in the individual observatories. Instrument and channels shown in the map “info balloon” are retrieved from the SOS, while the detailed metadata and real-time data plot on the left of Figure 8 are retrieved from the MBARI 1451 visualizer. Instrument data and metadata from any observatory that complies with IEEE 1451.0 can be displayed through this interface. Note that the individual observatories do not have to explicitly comply with OGC-SWE, since the STWS provides a bridge between IEEE 1451 and OGC-SWE.

C. Demonstration Features The test-bed has been demonstrated in the context of a

simulated harmful algal bloom (HAB) in Monterey Bay, an event which has clear implications for human health and commerce. Ryan et al [25] describe how oceanographic and meteorological conditions affect the formation and dispersal of

HABs in Monterey Bay. HABs often form along the northeastern shore of Monterey Bay near the point labeled “incubator” in Figure 9. Upwelling driven by strong

8

northwesterly winds can sequester the HAB to the incubator region, labeled “upwelling shadow”. However relaxation or reversal of the northwesterly wind leads to cessation of upwelling and “flushing” of the inner bay by offshore waters; under these conditions the HAB can be exported northward to the “shellfish beds” where toxins can enter the human food chain.

In this scenario, the interoperable test-bed includes the following instruments:

• An ASIMET wind sensor on a buoy in mid-bay which monitors wind speed and direction

• A WETLabs Triplet fluorometer which monitors chlorophyll concentration at the incubator site. (High chlorophyll levels are consistent with an algal bloom, but do not conclusively prove a HAB.)

• A Seabird CTD at the incubator site which monitors temperature and salinity. (Low salinity indicates flushing by offshore waters and potential northward export of the algal bloom.)

• Another WETLabs fluorometer and an RBR CTD which monitor chlorophyll and salinity at the shellfish beds and indicate the arrival of algal-laden water and potential toxins from the incubator site.

Note that the above instruments do not conclusively prove the presence of HAB species. In a real-world scenario, water samplers and genomic sensors could be deployed, perhaps on a mobile platform such as an autonomous underwater vehicle (AUV), to directly detect the presence of harmful species. The deployment of these more specialized assets could be triggered when the lower-cost conventional sensors indicate that a HAB might be underway.

Before the test-bed demonstrations, the MBARI instruments are plugged into the MBARI Mooring Controller in the lab and are immersed in tanks of seawater representing the incubator and shellfish bed sites. A wind sensor is mounted in the lab and a fan generates wind at appropriate strength and direction to indicate upwelling conditions. The instruments’ geo-location TEDS are configured to simulate appropriate positions in the bay rather than the real positions in the lab. During the demonstration chlorophyll proxy and fresh water are added to the seawater tanks to raise chlorophyll concentration and decrease salinity, indicating presence of alga and flushing of the bay, respectively. Fan speed is varied to simulate changing wind and upwelling conditions. The OOSTethys client displays instrument locations as retrieved from the Sensor Observation Service and metadata and sensor readings in near-real-time via the MBARI 1451 visualizer (Figure 8). The real-time data is typically displayed by the client within tens of seconds after it is acquired. The demonstration also includes plug-in of a PUCK-enabled instrument at the shellfish bed site; SIAM retrieves the driver and metadata from the instrument through PUCK protocol, executes the driver and makes the metadata available through the IEEE 1451.0 server. The OOSTethys client typically displays the new instrument location, data, and metadata within a minute or less of instrument plug-in.

Figure 9. SST image of Monterey Bay during upwelling, showing sensor locations for HAB scenario

Thus the test-bed demonstration shows how instrument interoperability enables fast monitoring and assessment of a potentially hazardous algal bloom, including capabilities to display sensor locations, data values, and detection of new instruments as they join the network.

V. SOME NEXT STEPS

A. Test-bed Performance The current test-bed relies on polling between SWE and

IEEE 1451 components to update states across the system. This is because the current SOS v1.0 specification [26] does not support asynchronous operations; instead, the SOS relies on a typical web service HTTP POST request/response mechanism for retrieving sensor information and observations. This approach can be quite inefficient, as reflected in sometimes sluggish performance of SWE clients. Asynchronous event notification between IEEE 1451 and SWE would enable much more timely and efficient update of SWE clients when instruments are installed into the network, change their position, acquire a sample, or otherwise change in an asynchronous way. Existing OGC-SWE specifications such as the Sensor Alert Service and Web Notification Service support asynchronous notifications, and the OGC is investigating ways of incorporating asynchronous operations in future versions of the SOS and other OGC specifications.

The current SOS implementation relies on many requests to the STWS in order to retrieve the latest information regarding available IEEE 1451 sensors. Information from the STWS is used to populate the SOS Capabilities document, which tells SOS clients what sensors and observations are available, as well as SensorML documents describing the sensors themselves and O&M observations describing the data coming from those sensors. The current implementation employs caching of many of the STWS responses in order to maximize efficiency, but more effective caching can be added to further improve efficiency. Caching can also be used on the SOS client to minimize the number of new requests that need to be made to the SOS in order to discover and describe sensors.

9

The current test-bed utilizes high-speed network links throughout. A more realistic design will incorporate low-bandwidth intermittent links to simulate satellite communications for moorings and perhaps acoustic links for underwater applications.

B. IEEE 1451 TEDS and SensorML IEEE 1451 and OGC-SWE each provide a metadata

framework to describe the characteristics of sensors. IEEE 1451 TEDS focus primarily on physical characteristics of sensors, instruments, and communication links which are closely associated with TIMs, whereas SensorML is applicable to high-level applications. SensorML provides a more comprehensive model that includes complex characteristics such as sensor data processing procedures and data acquisition schedules. Individual observatories in the current test-bed have no explicit notion of OGC-SWE and provide only TEDS to the IEEE 1451.0 layer. (The TEDS are subsequently mapped to basic SensorML elements by the Northrop Grumann SOS). However, the additional sensor information provided by SensorML (but apparently not by TEDS) can be extremely valuable in a broader sensor web. Hu et al [27] describe a TEDS-to-SensorML mapping scheme but also point out the complexities and limitations of their approach. An alternate approach could add a method to transfer “opaque” metadata through IEEE 1451.0. In our case, the observatory could transfer a SensorML document by this method. In any case, the TEDS-to-SensorML integration problem requires more research.

C. Additional Functionality The test-bed currently emphasizes data interoperability. As

a next step we plan to demonstrate the capability to configure and operate instruments through a standard Internet interface. This step will require integration and perhaps modification of the Sensor Planning Service and IEEE 1451 standards.

Thus far, the test-bed implements only a few methods in the IEEE 1451.0 standard; we plan to add more functionality in the future. Most of the test-bed instruments return raw data with a fixed and simple format that is easily mapped to the IEEE 1451.0 standard data format. We also plan to integrate instruments, such as acoustic doppler current profilers (ADCP) that generate more complex data structures.

D. CAN standards Controller Area Network (CAN) was originally developed

as a bus architecture for automobiles, but today is used in a wide variety of applications. The CAN-bus network provides a very efficient and robust platform for deterministic real-time applications of distributed sensors and actuators. Key advantages provided by CAN-bus include robust and efficient error detection and message transmission protocols. CAN-bus is based on OSI Reference Model layers 1 and 2 (physical and data link layers) and is standardized in ISO 11898 [28]. Several application-level standards have been developed to run on CAN-bus, notably the CANopen communication protocol and device profile specification [29].

Several oceanographic applications that use CAN-bus and CANopen for onboard communications have been implemented, including autonomous underwater vehicles and buoys [30][31], and at least one manufacturer [32] supplies oceanographic instruments for CAN-bus. We would like to investigate the use of CAN standards for future systems as well.

CANopen "device profiles” have been specified for several kinds of devices, including sensors and actuators [33]. Every CANopen device profile specifies an “object dictionary” that describes all parameters and variables of that device. Objects can be simple data-types such as bytes, integers, floating point values, and strings, but also more complex data types like arrays. Some dictionary objects are mandatory, others are optional. The object dictionary is stored in a TEDS-like electronic data sheet.

CANopen bears conceptual similarities to IEEE 1451. For example, in addition to the TEDS-like device profiles, CANopen's "CAN-master" component is responsible for managing network communications between devices and the network, similar to the IEEE 1451 NCAP. Unfortunately the IEEE 1451.6 CAN-bus working group is no longer active. Nevertheless we could explore integration of CAN with OGC-SWE standards, e.g., by "mapping" CANopen electronic data sheets to SensorML.

VI. CONCLUSIONS Diverse instruments and individual observatory

architectures can be integrated into a standards-based sensor network by taking the “adapter” approach we describe for our test-bed, without necessarily making extensive changes to the existing observatory infrastructure. Even instruments that do not implement any standard protocols can be made interoperable with this approach. Our experience indicates that integration with IEEE 1451.0 is quite straightforward; many of the standard 1451.0 requests were implemented by individual observatories in 1-2 weeks. Note that integration with IEEE 1451.0 also integrates the observatory with the considerably more complex OGC-SWE “for free”, since the NIST STWS provides a seamless bridge between IEEE 1451 and OGC-SWE. That is to say, individual observatories need only provide an interface with IEEE 1451.0 without explicitly referencing OGC-SWE protocol.

Standard native instrument protocols could greatly simplify instrument integration by removing manual installation and configuration steps, automating driver installation (MBARI PUCK), or eliminating the need for external drivers altogether (IEEE 1451.2).

MBARI PUCK protocol complements IEEE 1451 and OGC-SWE, as PUCK can store IEEE 1451 TEDS and/or SensorML metadata physically in the instrument itself and provides a protocol to automatically install those standard components on the network when the device is plugged in.

IEEE 1451.2 is still evolving and revisions in the near-future promise wide applicability to oceanographic RS-232 and RS-485 instruments.

10

ACKNOWLEDGMENTS We thank Drs John Ryan and Chris Scholin of MBARI for

their assistance in accurately simulating HAB conditions for Monterey Bay. We thank the COMET project (http://comet.ucdavis.edu) for allowing us to use part of their code as a basis for the real-time MBARI 1451 visualizer in our test-bed.

We offer many thanks to OGC’s Mark Reichardt, Carl Reed, and David Arctur for their guidance and encouragement. Thanks also to Ian Walsh of WETLabs for his advice on chlorophyll and particulate proxies.

** Commercial equipment and software, many of which are either registered or trademarked, are identified in order to adequately specify certain procedures. In no case does such identification imply recommendation or endorsement by the National Institute of Standards and Technology, nor does it imply that the materials or equipment identified are necessarily the best available for the purpose.

REFERENCES [1] ACT Workshop Report, “Enabling Sensor Interoperability”, Portland

Maine, October 16-18, 2006 [Online] Available: http://www.act-us.info/download/workshop_reports/ACT_WR06-07_Sensor_Interoperability.pdf

[2] W Elmenreich, S Pizek, “Smart Transducers–Principles, communications, and configuration”, Proceedings of the 7th IEEE International Conference on Intelligent Engineering Systems (INES), Assuit, Luxor, Egypt, March 2003, pp.510 -515.

[3] IEEE STD 1451.0-2007, Standard for a Smart Transducer Interface for Sensors and Actuators – Common Functions, Communication Protocols, and Transducer Electronic Data Sheet (TEDS) Formats, IEEE Instrumentation and Measurement Society, TC-9, The Institute of Electrical and Electronics Engineers, Inc., New York, N.Y. 10016, SH99684, October 5, 2007.

[4] E Song, K Lee, “Understanding IEEE 1451-Networked smart transducer interface standard”, IEEE Instrumentation & Measurement Magazine, Vol.11, No. 2, 2008, pp.11-17

[5] K Lee, “IEEE 1451: A Standard in Support of Smart Transducer Networking”, Proceedings of the 17th IEEE Instrumentation and Measurement Technology Conference, Baltimore, MD, May 1-4, 2000, Vol. 2, pp. 525-528.

[6] IEEE STD 1451.1-1999, Standard for a Smart Transducer Interface for Sensors and Actuators – Network Capable Application Processor (NCAP) Information Model, IEEE Instrumentation and Measurement Society, TC-9, The Institute of Electrical and Electronics Engineers, Inc., New York, N.Y. 10016, SH94767, June 26, 1999.

[7] E Song, K Lee, “Smart transducer Web services based on IEEE 1451.0 standard”, IMTC 2007-Instrumentation and Measurement Technology Conference. WARSAW, POLAND, MAY 1-3, 2007, pp.1-6.

[8] E Song, K Lee, “STWS: A unified Web service for IEEE 1451 smart transducers”, IEEE Transaction on Instrumentation and measurement, Vol.57, No.8, Aug. 2008, pp.1749-1756

[9] IEEE STD 1451.2-1997, Standard for a Smart Transducer Interface for Sensors and Actuators–Transducer to Microprocessor Communication Protocols and Transducer Electronic Data Sheet (TEDS) Formats, IEEE Instrumentation, SH99685, and Measurement Society, TC-9, The Institute of Electrical and Electronics Engineers, Inc., New York, N.Y. 10016, SH94566, September. 25, 1998.

[10] E Song, K Lee, “Service-oriented sensor data interoperability for IEEE 1451 smart transducers”, IMTC 2009-Instrumentation and Measurement Technology Conference, Singapore, MAY 5-7, 2009.

[11] M Botts, G Percivall et al, OGC White Paper, “OGC® Sensor Web Enablement: Overview and High Level Architecture”. Open Geospatial Consortium Inc., Date: 2007-12-28, Reference number of this document: OGC 07-165, Version: 3

[12] OGC Sensor Web Enablement [Online] Available: http://www.opengeospatial.org/projects/groups/sensorweb

[13] E Song K Lee, Integration of IEEE 1451 Smart Transducers and OGC-SWE Using STWS, SAS 2009 - IEEE Sensors and Applications Symposium, New Orleans, Louisiana, USA, 17-19 February 2009

[14] Introduction to SensorML [Online] Available: http://vast.uah.edu/index.php?option=com_content&view=article&id=14&Itemid=52

[15] K Lee, M Reichardt, “Open Standards for Homeland Security Sensor Networks”, IEEE Instrumentation & Measurement Magazine, Dec. 2005, Vol. 8, No. 5, pp.14-21.

[16] T O’Reilly, K Headley et al, “MBARI technology for self-configuring interoperable ocean observatories”, OCEANS 2006, 18-21 Sept. 2006, Page(s):1 – 6, Digital Object Identifier 10.1109/OCEANS.2006.306893

[17] K. Lee, “Sensor Standards Harmonization – path to achieving sensor interoperability”, 2007 IEEE Autotestcon, Baltimore, MD, Sept. 17-20, 2007, pp 381 – 388.

[18] Ocean Innovation 2008 World Summit, October 2008 [Online] Available: http://www.oceaninnovation.ca/2008/WorkshopLinks.asp

[19] NSF OOI Sensor Workshop, March 2009 [Online] Available: http://www.oceanobservatories.org/spaces/display/Presentations/OOI+Sensor+Workshop

[20] ESONET [Online] Available: http://www.ifremer.fr/esonet/ [21] C Artero, M Nogueras et al, “Diseño del sistema de control y

adquisición de datos del Observatorio Submarino ExpAndible (OBSEA)”. SAAEI08. Cartagena (España) Septiembre 9-11 de 2008

[22] C Artero, M Nogueras et al, “Control and acquisition system design for an Expandable Seafloor Observatory”. Oceans 2009, Bremen May 11-14, 2009

[23] IMSYS Technologies [Online] Available: http://www.imsystech.com [24] M Chaffey, L Bird et al, “MBARI's buoy based seafloor observatory

design”, OCEANS '04. MTTS/IEEE TECHNO-OCEAN '04 Volume 4, 9-12 Nov. 2004 Page(s):1975 - 1984 Vol.4, Digital Object Identifier 10.1109/OCEANS.2004.1406447

[25] JP Ryan, AM Fischer et al. “Influences of upwelling and downwelling winds on red tide bloom dynamics in Monterey Bay, California”, Continental Shelf Research, 29: pp 785-795

[26] OpenGIS Sensor Observation Service [Online] Available: http://portal.opengeospatial.org/files/?artifact_id=26667

[27] P Hu, R Robinson, J. Indulska, Sensor Standards: Overview and Experiences [Online] Available: http://nicta.com.au/__data/assets/pdf_file/0019/15652/Sensor_Standards-_Overview_and_Experiences.pdf

[28] "ISO 11898-1:2003 - road vehicles - controller area network (CAN) - part 1: Data link layer and physical signalling," 2003

[29] CiA (CAN in Automation): “CANopen”, 2002. EN 50325-4 Standard. [30] H Yoshida, T Aoki et al, "A working AUV for scientific research,"

OCEANS '04. MTTS/IEEE TECHNO-OCEAN '04 , vol.2, no., pp. 863-868 Vol.2, 9-12 Nov. 2004

[31] E. Kopiske,"DOLAN - Experiences with Iridium installed on the North Atlantic on a long time mooring", Iridium Satellite LLC workshop in Tempe, Arizona, Apr. 2006 [Online] Available: http://www.marum.de/Binaries/Binary13768/DOLAN_Iridium_Workshop_Tempe_full.pdf

[32] Aanderaa Instruments [Online] Available: http://www.aanderaa.com [33] CiA (CAN in Automation): “CiA 404: CANopen device profile for

measuring devices and closed-loop controllers “ [34] OWS-5 Demonstration [Online] Available

http://www.opengeospatial.org/pub/www/ows5/index.html