Project Deliverable D8 - Ifremer

Prototype implementation of example standardized sensor system

Rev.: 0.2

Doc. ID: ESONET-STD-0410 Status: Report

Release Date: 09/04/2010 of 19

Project contract no. 036851 ESONET European Seas Observatory Network

Instrument: Network of Excellence (NoE)

Thematic Priority: 1.1.6.3 – Climate Change and Ecosystems Sub Priority: III – Global Change and Ecosystems

Project Deliverable D8

TITLE Prototype implementation of example standardized sensor system

Due date of deliverable: month 30

Actual submission date of report: April 2010 Start of project: March 2007 Duration: 48 months Project Coordinator: Roland PERSON Coordinator organisation name: IFREMER, France Work Package 2 Organization name of lead contractor for this deliverable: KDM/MARUM Lead Authors for this deliverable: Christoph Waldmann

Revision 0.2

Project co-funded by the European Commission within the Sixth Framework Programme (2002-2006) Dissemination Level

PU Public x PP Restricted to other programme participants (including the Commission Services) RE Restricted to a group specified by the consortium (including the Commission Services) CO Confidential, only for members of the consortium (including the Commission Services)


Rev.: 0.2



Executive Summary One of the major crosscutting tasks within the ESONET project is to define best practices in regard to the handling, integration and operation of sensors and instruments within ocean observatories. Due to the scope and complexity of this topic a separate workpackage has been devoted within ESONET NoE to standardization and interoperability issues and one of the foremost objectives was to define interoperability concept for integrating sensors and instruments into ocean observatories in a standard way. Right from the beginning it was evident that a couple of concepts in regard to interoperability had already evolved in other fields as for instance remote sensing or in terrestrial sensor networks and candidate standards have been developed within this framework.

It is not the aim of the workpackage on sensor interoperability to define a comprehensive architecture for future ocean observatory systems. However, the goal was to investigate different concepts to be able to judge on specific solutions and come up with recommendations. What is described within this report is following this roadmap.

Within this activity appropriate standard approaches have been selected and tested. In particular the following schemes have been of interest -

• IEEE 1451.x standard series

• OGC Sensor Web Enablement (SWE)

The first is a so called field bus standard that allows for a unified connection and description of sensors. IEEE 1451 is defined independently of any specific protocol and is therefore well suited for ocean sciences where a huge diversity of instruments and according interface protocols exist. IEEE 1451 primarily addresses the Plug- and Work concept and is dealing with the hardware integration of sensor systems.

OGC Sensor Web Enablement is derived from the service oriented architecture and enables the distributed discovery, exchange, and processing of data across multiple sensor networks. It deals with the next higher level of sensor data processing where both SWE and IEEE 1451 are complementary. There are still some gaps in combining standards and this can only be addressed by implementing and testing them. For that purpose a test bed was developed that formed a platform for evaluating the standards (IEEE 1451, SWE, PUCK) under consideration. The central motivation of this exercise was to better understand the standard concepts to use this as a guideline for the implementation within ocean observatories.

Within this report an example implementation of a sensor following above mentioned standards are described. The results are summarized as lessons learned and recommendations in regard to future approaches.

The success of this endeavour is dependent on the acceptance by the user community. Therefore it was clear from the beginning that this activity has to be conducted in a networked manner calling together experts from European laboratories and linking this activity with international partners. Regular telephone conferences are assuring close exchange and a coordinated progress.


Rev.: 0.2




Author(s): Christoph Waldmann, Bremen University/MARUM

Abstract:

This document describes a prototype implementation of interface sensors to demonstrate the advantages of such an approach and the still existing deficiencies that exist. It is also meant to contribute to the definition of the ESONET label.


Rev.: 0.2



Contract References: (if required)

FP6 Project ESONET

Contract number 036851

Confidentiality, copyright and reproduction

Restricted–Confidential. This document has been prepared for the European Commission – European Co-operation office by the ESONET consortium in connection with a contract for a Network of Excellence implemented as specific support action and is submitted only on the basis of strict confidentiality. The contents must not be disclosed to third parties other than in accordance with the terms of the contract.

Document History:

Rev. Date Author(s): Comments

0.1 15/12/2009 C. Waldmann Format Initial Proposal

0.2 09.04.2010 C. Waldmann Revised version

Validated By:

Role: Name: Organization: Date Signature:

Approved By:

Distribution List:


Rev.: 0.2




CONTENTS

1.0 SCOPE 1.1 Background and Motivation 1.2 Document overview

1.3 Relationship to other tasks within ESONET 1.4 Applicable Documents

2.0 DESCRIPTION/CONCEPT OF OPERATIONS

3.0 DETAILED IMPLEMENTATION DESCRIPTION

3.1 OGC sensor interoperability experiment 3.2 PUCK integration at OBSEA observatory 4.0 EVALUATION

5.0 NOTES- Identification of gaps, lessons learned

6.0 Links to other projects

6.0 APPENDICES


Rev.: 0.2



1.0 SCOPE

1.1 Background and Motivation This document provides a conceptual description on how to achieve interoperability on the sensor level. Throughout this document interoperability is understood as a concept that allows instruments to be operated through a standard protocol and the instruments raw data can be processed through a standard set of tools (data interoperability). This definition indicates that interoperability addresses different levels and therefore it has to be specified what is actually meant with that. The concept presented here specifically addresses the aspects of system integration, test, and resource management. For that purpose functional blocks and their interfaces have to be defined and where the interfaces have to follow accepted standards. If in some cases standards are not suited special arrangement within the according community can be defined.

The prototype implementation that is described here is related to the conducted OGC interoperability experiment. This underlines the known need of exchanging information and experience on an international level to allow for broad acceptance. One immediate result is that the concept allows to making sensor data mutually accessible by each observatory in the world without specifically having to develop a software adaption to that.

1.2 Document overview The document describes the general concept and a practical implementation of existing standards followed by a practical example and the evaluation of the demonstrations. As the described implementation only makes use of a limited scope of the standards only according functions have been tested. Therefore the discussions and lessons learned will only cover these aspects. As other European projects also work on this topic complementary activities are described.

1.3 Relationship to other tasks within ESONET This task is related to activities within WP3 defining generic sensor packages and with WP9 on data management where OGC Sensor Web Enablement concepts play a role. The generic sensor package specification gives rise to requirements on the interface standard for instance what type of data and metadata have to be handled and how according instruments have to be controlled remotely. With WP9 there exists a well defined interface which in the frame of SWE is described by the Sensor Observation Service (SOS) which is implemented as part of WP9. 1.4 Applicable Documents This section lists the number, title, revision, and date of all standard documents that are of relevance for the standard implementation. Document types included are standards,


Rev.: 0.2



Government documents, commercial specifications and any other relevant documents such as technical notes:

(1) Electronics Industries Association, "EIA Standard RS-232-C Interface Between Data Terminal Equipment and Data Communication Equipment Employing Serial Data Interchange", August 1969, reprinted in Telebyte Technology Data Communication Library, Greenlawn, NY, 1985, no ISBN

(2) NMEA, National Marine Electronics Association, Januar 2002, Version 3.01

(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) P1451.1-Network-Capable Application Processor (NCAP) Model; defines a common object model describing the behaviour of smart transducers. Application software running in the NCAP based on IEEE 1451 communicated with transducers through the different IEEE 1451.X physical layer standards as required for a particular application. Communications among NCAPs and to higher level systems are supported in a network neutral manner.

(5) 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 - defines a transducers-to-NCAP interface and TEDS for a point-to-point configuration. Transducers are part of a Transducer Interface Module (TIM). This standard is being revised to add support for the popular serial UART interface.;

(6) P1451.3-Digital Communication and TEDS Formats for Distributed Multidrop Systems; defines a transducer-to-NCAP interface and TEDS for multi-drop transducers using a distributed communications architecture. It allowed many transducers to be arrayed as nodes, on a multi-drop transducer network, sharing a common pair of wires.

(7) P1451.4-Mixed-Mode Communication Protocols and TEDS Formats. (8) CAN/CAN-OPEN standard family -

ISO 11898-1:2003 Road vehicles — Controller area network — Part 1: Data link layer and physical signalling ISO 11898-2:2003 Road vehicles — Controller area network — Part 2: High-speed medium access unit

ISO 11898-3:2006 Road vehicles — Controller area network — Part 3: Low-speed, fault-tolerant, medium dependent interface

ISO 11898-4:2004 Road vehicles — Controller area network — Part 4: Time-triggered communication


Rev.: 0.2



ISO 11898-5:2007 Road vehicles — Controller area network — Part 5: High-speed medium access unit with low-power mode

CANopen has been established as European Standard EN 50325-4.

DeviceNet is a 7 layer communication protocol based on CAN which is mainly used in automation and control applications.

DeviceNet is predominantly used in the US. It has been developed by the company Allen-Bradley (belongs now to Rockwell Automation) and was subsequently offered as open standard to the ODVA (Open DeviceNet Vendor Association).


Rev.: 0.2



2.0 DESCRIPTION/CONCEPT OF OPERATION Instrument interoperability can be achieved through standards that are enforced at various layers within an observing system starting at the connectors and ending with high level protocols that are for instance based on the so called Service Oriented Architecture (SOA) like the OGC standard SWE. There are good reasons not to try to enforce the use of a single type of connector as this would prevent the scientific users of responding properly and flexible on the requirements of different platforms and instruments. On a higher level, however, standardization is feasible and delivers significant benefits. Figure 1 schematically describes some of the according protocol layers in an observing system. Physical instruments are considered to be at the lowest layer in the observatory protocol stack. Most of today’s digital oceanographic instruments have a RS-232 or RS-485 interfaces which communicate using very diverse proprietary command protocols and metadata and data formats, with virtually no standardization between manufacturers. The protocol built in to the instrument is designated as “native instrument protocol” in figure 1. 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 shall 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.

Figure 1: Interoperable instrument control layers


Rev.: 0.2



Many observatories have invested a lot 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. The topmost layer in figure 1 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). 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. 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. In this case access has to be managed through the observatory shore station.

Figure 2: The standardization layer stack

In figure 2 a more detailed description of the processing layers of sensor data within an observatory is given. IEEE 1451 is one standard that can be employed for integrating individual sensors into a network. There are other lower level standards around like CAN/CAN- OPEN that allow for integrating sensors into a network without the need of employing individual driver software for each instrument. However, CAN/CAN-OPEN does not define the interface to Web Services which would be needed for employing the OGC standard SWE. Yet, CAN/CAN-Open can be integrated into the family of IEEE 1451 standards which aims at establishing Web based sensor networks. In a similar way the MBARI PUCK concept can be seen as forming a subset to the more comprehensive IEEE 1451 functionality. This is illustrated in figure 3 where it is shown that PUCK is operating with RS232 as the interface standard and is mainly aiming at retrieving the data sheet of the

Figure 3: Relationship of IEEE 1451 to other standards


Rev.: 0.2



according instrument while IEEE 1451 is encompassing a number of interface standards and also addressing additional functions as for instance configuring the instrument under consideration.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. A smart transducer is the integration of an analog or digital sensor or actuator element, a processing unit, and a communication interface. 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. Figure 4 shows an IEEE 1451smart transducer schema, 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.

Figure 4: IEEE 1451 smart transducer schema


Rev.: 0.2



Figure 5: Comparison of Plug and Work Concepts

To exemplify the Plug and Work concept figure 5 shows a comparison between a purely IEEE 1451 based concept and a PUCK augmented approach. Within IEEE 1451 each instruments identifies itself at the SOS through for instance a push service employing a Web service compatible protocol (SOAP etc.). This is possible as all sensors can be interrogated with standard commands through a standard interface and are connected to a Web server specified by IEEE 1451.0. The transducer electronic datasheet (TEDS) is transmitted to the SOS and allows a unique identification and description of the according instrument. With PUCK typically only a subset of the IEEE 1451 functionality is realized which calls for a special procedure to realize Plug and Work, i.e. polling by a dedicated host manager to check for new sensors in the network. From that perspective PUCK does not appear as a big advantage at first glance. However, IEEE-1451 and OGC SWE are rather complex, which is to be expected as these standards are also quite comprehensive. This complexity presents challenges for instrument manufacturers who must thoroughly understand the standard and who must correctly implement it in firmware. Moreover embedded instrument processors are often designed for low cost and low-power environments, and hence may not be capable of fully implementing the standards. Another drawback is that manufacturers would likely have to abandon existing instrument firmware that does not implement the standard; this existing firmware often represents a very considerable investment by the manufacturer. The foregoing gives a reasoning why PUCK protocol has been introduced and where it can bring added-value. It does not itself implement interoperability, but rather provides the lower tier in a hierarchy of standards that achieve this goal. PUCK defines a simple standard embedded instrument protocol to store and retrieve information from the instrument. The information consists of a minimal instrument datasheet that includes a universally unique instrument serial number, a manufacturer ID, and a small amount of other metadata PUCK


Rev.: 0.2



protocol also allows an optional “payload” consisting of any information needed by a particular observing system.

3.0 DETAILED IMPLEMENTATION DESCRIPTION 3.1 THE OGC SENSOR INTEROPERABILITY EXPERIMENT

The ESONET group was actively involved in the development of an interoperable instrument test-bed in collaboration with OGC and members of the Sensor Standards Harmonization Working Group (SSHWG) led by the National Institute of Standards and Technology (NIST). The goal of this effort was 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 [17] and has since been refined. The test-bed integrated 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) 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 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 6).

Figure 6: Test bed architecture


Rev.: 0.2



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. 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. 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 [15]. 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. 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.


Rev.: 0.2



3.2 PUCK INTEGRATION AT OBSEA OBSERVATORY At OBSEA Observatory, two CTDs have been used to test the integration of PUCK protocol. These instruments were a RBR CTD with PUCK implemented in firmware and a Seabird CTD with an external PUCK hardware. Two different metadata files were implemented for each instrument: a SensorML file and a XML IEEE 1451 TEDS file. These files are stored in the PUCK payload memory. Each file is preceded by a tag that specifies the file type, as shown in Table 1 (the tag format and attributes will be proposed as an addendum to the PUCK version 1.3 specification).ad

Table 1. Recommended Payload type name

A web-based tool has been developed to simplify creation of SensorML and IEEE 1451 TEDS files for specific instruments, using consistent syntax and attribute names. The needed document is generated from user entries describing the structure of the sensor system (system type, variables, and subsystems) employing URIs (Uniform Resource Identifiers) containing standard entries for sensor types and variables. Furthermore the available lists are populated with definitions registered in the MMI Ontology Registry and Repository, ORR, http://mmisw.org/orr [23]. The communication between instruments (in this case 2 CTDs) and the NCAP host computer is implemented by a serial RS232 link. The host computer is running an IEEE1451.0 HTTP server and an automatic instrument recognition algorithm to automatically detect a new instrument plugged into a serial port. This detection protocol is shown in figure 7. The host computer periodically interrogates the serial port for a PUCK response from the serial port, the host retrieves the 96-byte PUCK datasheet and examines the UUID to determine if a new instrument has been installed. If so, the host retrieves the SensorML and IEEE 1451 TEDS description from the instrument’s PUCK payload, and loads an appropriate driver. Finally the driver retrieves a new data sample from the instrument. These operations are performed at the sampling frequency specified for the instrument.


Rev.: 0.2



Figure 7: Automatic instrument recognition protocol

4.0 EVALUATION A. Test-bed Performance The current test-bed relies on polling between SWE and IEEE 1451 components to update states across the system, i.e. realize the Plug and Work concept. This is because the current SOS v1.0 specification [21] 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. 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,


Rev.: 0.2



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. 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 [22] 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 Thus far, the test-bed implements only a few methods in the IEEE 1451.0 standard. 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. In a next step instruments, such as acoustic doppler current profilers (ADCP) that generate more complex data structures has to be integrated into the test-bed architecture. 5.0 NOTES- Identification of gaps, lessons learned Diverse instruments and individual observatory architectures can be integrated into a standards-based sensor network by taking the “adapter” approach which means that an intermediate device is mediating between the proprietary and the standard interface/protocol. Even instruments that do not implement any standard protocols can be made interoperable with this approach. The integration with IEEE 1451.0 also allows a seamless integration of the observatory with the considerably more complex OGC-SWE, since the NIST STWS provides a bridge between IEEE 1451 and OGC-SWE. Individual observatories only have to 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.

6.0 Links to other projects

Due to the attractive features there are a number of projects that are addressing sensor networks that are designed to use SWE architecture. One of the prominent projects are the EU funded Integrated Project SANY that terminated in December 2009. Within this project SWE concepts have been employed and tested in different scenarios. However, the SANY project did not specifically addressed issues that dealt with standardization on the hardware level. Referring to figure 2 of this report SANY mainly dealt with the two topmost layers of the stack, the SWE and application layer. Therefore it would be a natural choice to combine ESONET and SANY activities. First discussions were started during the EGU General Assembly in Vienna in April 2009.


Rev.: 0.2



7.0 APPENDICES References and relevant publications: [1] Del Rio, J., et al.: Evaluation of MBARI PUCK protocol for interoperable ocean observatories, THIRD INTERNATIONAL WORKSHOP ON MARINE TECHNOLOGY, VILANOVA i LA GELTRÚ (BARCELONA), NOVEMBER 19-20, 2009 [2] Bermudez, L., et al., Ocean Observing Systems Demystified, OCEANS’09, Biloxi, USA, October 2009 [3] Reilly et al., Instrument Interface Standards for interoperable Ocean Sensor Networks, OCEANS’09, Bremen, Germany, May 2009 [4] Fairgrieve et al., PULSENetTM: An Implementation of Sensor Web Standards, 2009 International Symposium on Collaborative Technologies and Systems, Baltimore, MD, USA May 18-May 22, ISBN: 978-1-4244-4584-4 [5] Klopfer et al., SANY an open service architecture for sensor networks, ISBN 978-3-0-028571-4, 2009 [6] 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] 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. [10] 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 [11] OGC Sensor Web Enablement [Online] Available: http://www.opengeospatial.org/projects/groups/sensorweb [12] E Song K Lee, Integration of IEEE 1451 Smart Transducers and OGCSWE Using STWS, SAS 2009 - IEEE Sensors and Applications Symposium, New Orleans, Louisiana, USA, 17-19 February 2009 [13] Introduction to SensorML [Online] Available: http://vast.uah.edu/index.php?option=com_content&view=article&id=14 &Itemid=52 [14] K Lee, M Reichardt, “Open Standards for Homeland Security Sensor Networks”, IEEE Instrumentation & Measurement Magazine, Dec. 2005, Vol. 8, No. 5, pp.14-21.


Rev.: 0.2



[15] 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 [16] K. Lee, “Sensor Standards Harmonization – path to achieving sensor interoperability”, 2007 IEEE Autotestcon, Baltimore, MD, Sept. 17-20, 2007, pp 381 – 388. [17] Ocean Innovation 2008 World Summit, October 2008 [Online] Available: http://www.oceaninnovation.ca/2008/WorkshopLinks.asp [18] C Artero, M Nogueras et al, “Control and acquisition system design for an Expandable Seafloor Observatory”. Oceans 2009, Bremen May 11- 14, 2009 [19] IMSYS Technologies [Online] Available: http://www.imsystech.com [20] 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 [21] OpenGIS Sensor Observation Service [Online] Available: http://portal.opengeospatial.org/files/?artifact_id=26667 [22] 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 [23] Rueda, C., Bermudez, L., Fredericks, J. The MMI Ontology Registry and Repository: A Portal for Marine Metadata Interoperability. MTS/IEEE Oceans'09. Biloxi, Mississippi. October, 2009.

Project Deliverable D8 - Ifremer

Documents

Transcript of Project Deliverable D8 - Ifremer