Interoperability experiments at OBSEA

INTEROPERABILITY EXPERIMENTS AT OBSEA Joaquin del Rio1, Tom O’Reilly2, Daniel Mihai Toma1, Antoni Manuel1 1-SARTI Research Group. Universitat Politècnica de Catalunya (UPC). Spain 2-MBARI Monterey Bay Aquarium Research Institute. USA Introduction ESONET needs a Web portal with real-time web interface from online observatories. In order to do so, online data are urgently needed. This was one strong demand during the 2009 review of ESONET in Brussels. Actually each observatory has their own software architecture and data management processes. Some standards can be applied on top of each observatory’s data management in order to access data from internet in a standard way. Some of these standards can be SensorWebEnable, IEEE1451.0. or initiatives like DataTurbine for high speed real time data streaming. The use of these standards in an observatory to access data and metadata from a general web interface can provide interoperable data visualization from the user point of view. Another issues, not related with data access or data visualization, are important to archive interoperability between observatories as plug and work capabilities of the instrument. Initiatives as MBARI PUCK protocol (for RS232 or IP), interfaces like the SmartSensorBoard (Ifremer,UPC) or recently the SID, Sensor Interface Descriptor (52North), are being tested at Western Mediterranean Observatory OBSEA. Other interoperability issues for standardization about access to data archives is now starting at OBSEA taking into account the experience about previous initiatives like SeaDataNet and standards proposed by INSPIRE for metadata specification like ISO19115 and NetCDF for data transport. Time synchronization in cabled observatories by Ethernet networks can be achieved implementing IEEE1588 Precision Time Protocol (PTP) versus NTP or SNTP for applications with needs of synchronization under milliseconds. Actual observatories had been deployed before IEEE1588v2 was released, and for these reason junction boxes are not equipped with IEEE1588v2 Ethernet switches. Some test experiments has been carry out in order to test PTP under non PTP switches in order to evaluate the time synchronization accuracy for these type of networks. Figure 4 shows one of the test setup to provide GPS information to an instrument through a IEEE1588 synchronization network. About OBSEA OBSEA is a cabled seafloor observatory 4 km offshore Vilanova i la Geltru (Barcelona, Spain) coast located in a fishing protected area, and interconnected to the coast by an energy and communications mixed cable. The main advantage of having a cabled observatory is to be able to provide power supply to the scientific instruments and to have a high bandwidth communication link. In this way, continuous realtime data is available. The proposed solution is the implementation of an optical Ethernet network that transmits continuously data from marine sensors connected to the observatory. With OBSEA, we can perform a real time observation of multiple parameters in the marine environment. SARTI research group from the Technical University of Catalonia (UPC) is devoted mainly in the design and deployment of sensor networks, from the elecronical, mechanical and data managment point of view. In this case, OBSEA was a new challenge, and now it is a perfect place where scientist are able to collect data, test new instrumentation and procedures. IEEE-1451 and OGC SWE Integration into actual Observatories In most cases, actual observatories are using a proprietary Data Management and Instrument control framework. We can divide the interoperability problems in different parts from bottom (instrument or sensor side) to top (user access to real-time data and archive). At figure 2 we can see a simple approach to achieve interoperability to real time data. The integration at the actual proprietary Data Management system of different observatories of different services like IEEE1451 server or SWE SOS server can offer access to data using web clients without disturbing the actual functionality off the observatory. The IEEE 1451 provides a specification to add a digital layer of memory, functionality, and communication to sensors. For example it enables sensors to be controllable and their measurements accessible through a network with sufficient information on the sensor characteristics and history. OGC Sensor Web Enablement (SWE) provides a specification to Web-enabled sensors to be accessible and, where applicable, controllable via the Web. SOS provides a broad range of interoperable capability for discovering, binding to, and interrogating individual sensors, sensor platforms, or networked constellations of sensors in real-time, archived or simulated environments. Up to now, we can consider these standards in the top level services to provide real-time data to users in a standard way. Figure 1 OBSEA Structure Instrumentation Viewpoint / 10 / Winter 30 PUCK protocol and SensorML with Sensor Interface Descriptor (SID) Another approach for instrument manufacturers is to implement PUCK protocol in their instrument firmware. PUCK has been formally proposed as an OGC Sensor Web Enablement standard. PUCK does not itself fully implement interoperability, but rather provides the lower tier in a hierarchy of standards that achieve this goal. PUCK protocol is a simple command protocol that helps to automate the configuration process by physically storing information about the instrument with the instrument itself. The protocol defines a small “PUCK datasheet” that can be retreived from every compliant instrument; the datasheet includes a universally unique identifier for the instrument as well as metadata that includes manufacturer and model. Additional information called “PUCK payload” can be stored and retrieved from the instrument. The payload format and content are not constrained by PUCK protocol, and can include executable driver code that implements a standard operating protocol as well as metadata that describe the instrument in a standard way, or any other information deemed relevant by the observing system. PUCK protocol commands augment rather than replaces existing instrument commands, and so manufacturers do not have to abandon their existing software. PUCK protocol is simple, and readily implemented in even simple instrument processors; several manufacturers now implement MBARI PUCK protocol in their instruments. PUCK protocol was originally defined for instruments with an RS232 interface. A proposed revision extends the protocol to Ethernet interfaces; the “IP PUCK” protocol includes the use of Zeroconf to enable easy installation and discovery of sensors in an IP network. The OBSEA team has developed an automatic algorithm to detect the installation of RS-232 PUCK instruments. The host computer periodically interrogates the serial ports for a PUCK enabled instrument. When the host receives a PUCK response from the serial port, the host retrieves the UUID to determine if a new instrument has been installed. If so, the host retrieves the PUCK payload and uses this information to collect data from the instrument and register it in WEB using standards like IEEE 1451.0 or OGC SWE. The detection algorithm for IP PUCK-enabled instruments is based on the Zeroconf standard. When an IP PUCK instrument is plugged into a local area network (LAN), it automatically gets an IP address and is registered as a PUCK service via Zeroconf. An application that runs in the same LAN can discover the instrument and retrieve the PUCK payload through PUCK protocol and automatically register the new instrument in a standard way in WEB. Thus standard IEEE-1451 and OGC SWE components can be automatically retrieved and installed by the host when a PUCKenabled instrument is plugged in, overcoming the difficulties of manual installation. An important component to achieve the plug and play capability with PUCK protocol is the payload information attached to each instrument. The payload should describe entirely the functionality of the instruments in a standard way and should be machine and human readable. To accomplish this task SensorML with Sensor Interface Descriptor (SID) can be used, which provides standard models and an XML encoding for describing sensors, measurement processes, and instrument control information. As we know, instruments are using proprietary command protocols to communicate. The development of software drivers is needed in order to integrate them in each platform. SID can help to avoid the process of write instrument drivers. The generation of a machine readable document with information about how to communicate and parse the information will help the plug and play process. Figure 3 shows how services running a SID interpreter can establish the connection to a sensor and are able to communicate with it by using the sensor protocol definition of the SID. SID instances for particular sensor types can be reused in different scenarios and can be shared among user communities. (before) Figure 2 Access to real-time data using standards like SWE SOS or IEEE1451 Figure 3 SID interpreter in a data Acquisition System (proposed to OGC by 52North) The Smart Ocean Sensors Consortium The Smart Ocean Sensors Consortium (SOSC) is a group of manufacturers and users dedicated to improving the reliability, utility and economy of hydrographic sensor networks. The SOSC aims to accomplish these goals through the development, adoption and promotion of practical standard interfaces and protocols. The SOSC was founded on the initiative of Canadian instrument manufacturer RBR Ltd in early 2009 following an OGC-sponsored interoperability workshop in St John’s Newfoundland. Neil Cater of Memorial University’s Marine Institute was elected first consortium chairman. Sensor manufacturer members include European companies SEND Electronics Gmbh and SiS Gmbh, as well as manufacturers from Canada and the USA. Non-manufacturer members include representatives from ESONET, SARTI-UPC, the Monterey Bay Aquarium Research Institute (MBARI), the US Ocean Observatories initiative, NOAA, and other organizations. Members pledge to offer and use instruments that comply with interfaces and standards designated as “consortium approved”. Membership is open to organizations that share consortium goals, and membership requests are subject to approval by the SOSC chairman. The SOSC collaborates with the Open Geospatial Consortium (OGC), which has established the Sensor Web Enablement suite of interoperability standards. The two consortia have signed a formal memo of understanding, resolving that they will cooperate to pursue common goals. SOSC manufacturers plan to provide a standard description of each of their instruments, and are evaluating the OGC’s SensorML markup language for this purpose. The manufacturers also agree to define a standard protocol to uniquely identify the make, model, and serial number of each compliant instrument. The two consortia have agreed to collaborate on formal submission of PUCK as an OGC standard. Instrument manufacturers provided very useful feedback to the OGC standard working group during this process, and SOSC member SARTI-UPC has actually implemented an “Ethernet PUCK” instrument to verify the feasibility of the proposed standard. The SOSC and OGC also work together to demonstrate sensor network technologies such as PUCK, OGC Sensor Web Enablement, IEEE 1451, and other standards. These “live” demonstrations are held at conferences, and usually involve SOSCOGC team members and sensors distributed across the planet, integrated in real-time thanks to the Internet and interoperability standards. Instrumental Viewpoint / 10 / Winter 31