Cyberinfrastructure Point of Presence (CyberPoP)

The primary physical hardware and software building block and configuration item for the CI is the CyberInfrastructure Point of Presence (CyberPoP). It provides computation, storage and network resources at a designated installation site as part of the OOI network. A CyberPoP contains a CI Capability Container described in above. There are several classes of CyberPoPs:

• Observatory Acquisition Point (OAP)
• Observatory Distribution Point (ODP)
• Observatory Execution Point (OEP)
• Operations Management Point (OMP)
• Marine Execution Point (MEP)
• Instrument Development Kit (IDK)
• National Internet Infrastructure (NII)

Figure 2. Types of physical CI deployments, CyberPoPs (SV-1)

The Observatory Acquisition Point (OAP) is a hardware environment to be deployed within a protected data center facility, comprising a CI capability container configuration that provides the primary point of access for Marine observatories to the CI and all the necessary computational, storage and network resources in a redundant layout. It provides a highly reliable, scalable and secure environment for data acquisition, initial data processing such as segmentation and QA/QC and data preservation.

The Observatory Distribution Point (ODP) is a hardware environment comprising a CI capability container configuration for OOI data distribution across the distribution network and for peering with external network providers, cloud execution and storage environments such as the Amazon Elastic Cloud and the Teragrid.

The Observatory Execution Point (OEP) is CI capability container configuration to be deployed either on OOI operated hardware or in cloud execution environments. OEPs can be provisioned on demand when required for the execution of user processes, such as numerical models and data visualizations. The CI provides Common Execution Infrastructure services for the elastic provisioning of such CyberPoPs in cloud environments, such as the Amazon EC2 and Scientific Clouds based on the TeraGrid.

The Operations Management Point (OMP) is an environment comprising hardware and a CI capability container configuration deployed at various physical locations close to marine observatory and CI control centers, providing observatory network and resource operations and state of health monitoring capabilities.

The Marine Execution Point (MEP) is a hardware environment and a CI capability container configuration to be deployed in science payload hardware environments of marine observatory infrastructure, such as aboard global buoys and AUVs. MEPs interface with proprietary instrument and platform controller software and represent their resources and capabilities to the OOI network. MEPs do not modify or replace existing software and hardware installations but instead provide a layer on top of them with direct connectivity to the OOI integrated observatory network. The hardware configuration in a MEP deployment is limited in terms of available computational, storage, power and bandwidth resources. The MEP is designed to be independent of the computational and storage hardware environments embedded in off-the-shelf marine infrastructure and instrumentation components. However, the software environment around the CI capability container supports the direct deployment on available hardware, providing sufficient power, computational and storage resources are provided.

The Instrument Development Kit (IDK) is an environment comprising hardware and a CI capability container configuration that will be used for dry and wet system testing of sensors and instrument platforms and their driver software, before their actual deployment on marine observatory OOI infrastructure in the field.

The National Internet Infrastructure (NII) provides the communication network environment for the OOI integrated observatory. For its high bandwidth (data) distribution network, it is based on the CI IO operated exclusive Layer-2 10 Gigabit Ethernet network loop around the US using National Lambda-Rail infrastructure. Furthermore, it makes use of routed Internet-2 IP network infrastructure to provide access to the public Internet and as redundant lower bandwidth management network for the distributed OOI installation sites. The different CyberPoP configurations are clients to these networks.

CyberPoP Deployment

Capability Container Deployment

(partly outdated)

Figure 4.3.5-1 illustrates the deployment of tailored CI Capability Container services for the data collection activity scenario throughout the observatory network. It makes use of the various CyberPoP configurations as introduced in the Section 4.3.4. This specific scenario assumes a low bandwidth, intermittent connection between the physical instrument interface of the CI with its acquisition capabilities and the remainder of the CI network. Because of the resource-constrained nature of this scenario, the Instrument Point Capability Container provides only general CI infrastructure and instrument proxy services. The Acquisition Point Capability Container illustrates the use of infrastructure services to implement the processes in the data collection activity scenario. Both Instrument Point and Acquisition Point are deployed as Marine Execution Point CyberPoPs, MEP.

Figure 4.3.5-1 Capability Container Deployment Model (Global Mooring Scenario)

On the shore side, the Ingest Point (deployed in an Observatory Acquisition Point CyberPoP OAP) is responsible for accepting data from a low bandwidth satellite based network and for providing data repository ingestion, cataloging, metadata association services.

The process execution infrastructure service provides the filtering and triggering processes in this Capability Container. An additional function supported by the Capability Container is the presentation capability implemented in the Access Portal Cap Container. It contains portlets for session management and Google Earth presentation drawing upon design references from the BIRN/Telescience GridSphere-based portal framework, as well as an http container.
The infrastructure elements that support the Data Collection Activity of a global scale, buoyed observatory are one deployment scenario. This spans the entire range of deployed systems and networks from ocean-based instruments to CyberPoPs and user applications.

The Instrument Point represents the interface between the physical world and the CI; it comprises proxies that provide a programming interface to the instruments. The Acquisition Point provides instrument control and data acquisition and transmission functions. It comprises a process and instrument controller and a data acquisition subsystem. Researcher-supplied triggers initiate data acquisition processes that the process controller translates into commands for the instrument controller.

Data from the instruments transit from the instrument controller to the acquisition component, where researcher-supplied filters result in either new data acquisition or transmission of the data to the Ingest Point. Data are sectioned appropriately by a segmentation component for transmission and handed over to the transport broker, which internally may use an Object Ring Buffer (ORB) and the communications controller to locally store and transmit the data, respectively, based on network availability and Quality-of-Service (QoS) constraints. At the Ingest Point, data arrive via the local communications controller and transport broker. The latter feeds data correction and ingestion components. The ingested data, along with their metadata, are buffered via the local storage broker.

The storage broker interacts with the Storage Point that offers repositories for data and services, as well as data and metadata cataloging. The researcher has multiple ways to view and further process data. First, an Access Portal supports data access and presentation via web and other browsers. It interfaces with the Storage Point via a local storage broker and offers components for search, navigation, and presentation. Second, an Application Integration Point supports data access, transformation and analysis via a set of analysis tools. It also connects to the Storage Point via a local storage broker, and offers programming interfaces so that researcher-supplied analysis and transformation processes can access and manipulate the data.

In this deployment scenario, the Sensing & Acquisition subsystem provides services to be deployed on the Instrument Point, namely the platform and instrument agents, acquisition and segmentation components, transport broker, ORB and communications controller of the Acquisition Point, as well as the communications controller and transport broker of the Ingest Point draw upon BRTT Antelope® components for the integration of existing instrument adapters and data processing components. The Data Management subsystem comprising the storage provider with its repositories and catalogs at the Storage Point and the federated storage brokers of the Ingest Point, Access Portal, and Application Integration Point are built from UCSD iRODS components. Presently, v1.0 of the ROADNet PoP (RPoP) integrates Antelope and SRB, the predecessor of iRODS, in a small, low-power, low-cost LINUX box using Intel XScale Processors. The next operational release will include web services support.

The Common Execution Infrastructure is implemented using researcher-provided filter and trigger processes in the Acquisition Point, a data correction process in the Ingest Point, a presentation process in the Access Portal, and the transformation and analysis processes in the Application Integration Point, where the visualization and modeling capabilities of, for example MatLab, are also provisioned.

The science data management functionality of the Data Management subsystem, comprising ingest and metadata cataloger components at the Ingest Point, the metadata-based search and navigate components of the Access Portal, and the navigate component of the Application Integration point, are implemented based on design references from the MBARI Shore Side Data System (SSDS). The repositories and catalogs at the Storage Point are implemented using OOI-specific adaptations of iRODS repositories and catalogs currently deployed for BIRN/Telescience, with necessary extensions to house service repositories. All infrastructure elements are implemented using a Rich Services Deployment Pattern. They are shown with their particular plug-ins.