OV-2: Operational Node Connectivity Description

1.1 Product Overview The Operational Node Connectivity Description graphically depicts the operational nodes (or organizations) with needlines that indicate the requirement to exchange information between any pair of nodes. The graphic includes operational nodes internal to the architecture as well as those external to it. The OV-2 product may be modeled using collaboration diagrams, where actors (instances of those in OV-5’s use case diagrams) represent the roles or organizations that communicate via UML links and UML messages (needlines and information exchanges). Operational nodes also correlate to classes on the corresponding OV-4 UML class diagram.

1.2 Document History Date Version By Description of Changes 2006.03.09 0.1 John Graybeal Template only 2006.05.28 1.1 Alan Chave Initial draft 2006.05.30 1.2 Alan Chave Initial release 2006.07.26 1.3 Alan Chave Final release

1.3 Product Purpose and Description OV-2 is intended to track the need to exchange information between specific operational nodes that play key roles in the architecture and other nodes. OV-2 does not depict the connectivity between the nodes. The main features of this product are the operational nodes and the needlines between them that indicate a requirement to exchange information. An operational node is an element of the operational architecture that produces, consumes, or processes information. What constitutes an operational node can vary among architectures, and includes, but is not necessarily limited to, representation of an operational/human role, an organization or organization type.

A needline documents the requirement to exchange information between nodes. The needline does not indicate how the information transfer is implemented. Needlines are represented by arrows (indicating the direction of information flow) and are annotated by a phrase that is descriptive of the principal types of information exchanged. It is important to note that the arrows on the diagram represent needlines only. There is a one-to-many relationship from needlines to information exchanges.

1.4 Representations A key purpose of the ORION cyberinfrastructure is provision of a distributed and federated capability to describe and utilize resources and activities or processes operating on and with resources. As defined in the dictionary (AV-2), the term resource encompasses representations of physical entities that can be utilized via the cyberinfrastructure; examples include instruments, networks, registries, repositories, or data. Any function associated with a resource is presented as a service, and is itself a resource. An activity is a task or grouping of tasks that provides a specialized capability, service, or product. A process is a running instance of an activity or set of

related activities. Since many resources will be shared and hence subject to use conflicts, a mechanism that enforces policy to arbitrate rights and allocations is essential. These four elements – resources, activities, processes, and policy – operate at many levels with complex linkages throughout ORION, and beyond to non-ORION systems. Further, they are dynamic and multivariate; it is possible for a policy to change as resource utilization evolves. It is also possible for a single instance of a resource (e.g, a raw data stream which is a realization of a random variable that cannot be duplicated) to be used by one or more processes (e.g., different numerical models) to produce multiple new resources (e.g., the data products produced by each model). These concepts and their complex interactions are illustrated in OV-2 by a top-level Observatory Network Model containing five operational nodes and detailed views breaking each of these down into a set of principal activities. The Observatory Network Model also defines a Common Service Model to provide the core cyberinfrastructure services required to implement its functionality. Finally, four instantiations (Observatory, Laboratory, Classroom, and Facility) of the Observatory Network Model that contain the core activities of an ocean observatory are outlined, each serving different purposes and classes of actors.

The five detailed views that expand the operational nodes in the Observatory Network Model are presented in distinct subsections. The Instrument view describes the interplay of sensors and actuators with observatory physical nodes and the remainder of the observatory. The Observatory Management view defines the operational nodes required to manage and allocate distributed resources throughout an ocean observatory. The Analysis and Synthesis view contains the key elements required to couple observations with hypothesis testing and define new observation missions with participant actors in the loop. An important subclass of Analysis and Synthesis is the Interactive Analysis and Visualization Model that links Investigator actors and analysis and visualization Expert actors into a loose collaborative relationship. The Mission Planning view describes the interactions needed to define and organize an observation program. Finally, the central Knowledge Network node represents the main link between the Observatory Management, Analysis and Synthesis, and Mission Planning nodes. The Knowledge Network archives not only data and their resultant products, but also the experience and understanding gained through use of an observatory. Experience and understanding are typically realized as declarations of provenance and citation or statements of evaluation and correspondence.

1.4.1 Observatory Network Model Figure 1 shows the operational nodes and needlines for the Observatory Network Model. The operational nodes in this model are expanded in five detailed views and one subclass. Figure 1 also defines the elements of a Common Service Model for the core services needed by both the distributed operational nodes and four instances of the Observatory Network Model defined along the bottom of the figure.

Overlapping subgroups of the operational nodes in Figure 1 comprise four operational domains. The Instrument and Observatory Management make up the Instrument Network domain that is focused on the collection of observations. The Observatory Management, Analysis and Synthesis, and Knowledge Network nodes constitute the Knowledge Acquisition domain that is centered on the utilization of observations. The Analysis and Synthesis, Mission Planning, and Knowledge Network nodes comprise the Analysis and Decision domain in which observations are distilled to formulate testable hypotheses that lead to new observation efforts. The Mission

Planning, Observatory Management, and Knowledge Network nodes constitute the Interactive Inquiry domain focused on programs of coordinated, hypothesis-driven observations.

The Instrument operational node comprises distributed instruments containing sensors and actuators linked to observatory physical nodes and an Observatory Management operational node. The Instrument Network node provides data from sensors, instrument status information, and requests for resources such as bandwidth or power to the Observatory Management node. It receives instructions to instruments and allocations of resources from the Observatory Management node.

The Observatory Management operational node contains functionality to manage and allocate observatory resources for use in the Instrument Network node. It provides observations to the Analysis and Synthesis node, and receives observation plans from the Mission Planning node. It also provides command and control instructions and resource allocations to the Instrument node, and receives data, status information, and resource requests from the Instrument node.

The Analysis and Synthesis operational node provides a wide range of event detection/response, quality control, hypothesis formulation, and modeling capabilities linked together via the central Knowledge Network node. It provides observation requests to the Mission Planner node and receives observational data via the Observatory Management node. It also interacts with human

Figure 1. The Observatory Network Model

actors through analysis and visualization activities defined by the Interactive Analysis and Visualization Model.

The Mission Planning operational node schedules specific resources (e.g., mobile platforms or collections of instruments) and configures them to accomplish a task, usually within the context of an ongoing laboratory or classroom activity. It receives observation requests from the Analysis and Synthesis node, and provides observation plans to the Observatory Management node. The Knowledge Network node binds the Observatory Management, Analysis and Synthesis, and Mission Control nodes together, capturing and disseminating the comprehensive experience and understanding gained through use of the Observatory Network. At its core, the Knowledge Network provides catalog and repository services to all of the main operational nodes defined in Figure 1, and links groups of human actors in virtual Observatories, Laboratories, Classrooms, and Facilities together into an overall Observatory Network. The Observatory, Laboratory, Classroom, and Facility are instances (which are instantiated dynamically and may operate simultaneously) of the Observatory Network Model that utilize different classes of resources subject to distinct policy constraints to accomplish diverse goals. For example, an Observatory plays an oversight role through connection of resources with a wide range of management and interchange activities, and is overseen by an Operator actor. A Laboratory establishes a virtual relationship between a group of Investigator actors and all of the resources and activities required to accomplish their set of scientific goals. The Classroom achieves educational goals by joining resources and teaching activities. It is overseen by Educator actors and interacts with Student actors. Finally, a Facility provides resources to the observatory network subject to policy constraints, and is managed by a Provider actor. A broad range of common services is required to bind the observatory network into a coherent whole. Mediation services provide the mapping of information between senders and recipients who use different vocabularies, and define a standard ORION vocabulary. Enrichment services support the ongoing process of characterizing and improving the understanding of data and the information derived from them. The enrichment process must be an open one that is in a continuous state of refinement, analogous to the manner in which Wikipedia evolves. Analysis consists of standard services needed to qualify data and derive data products from them, including quality control/assurance and event detection, along with a modeling framework. They operate in a closed loop with Enrichment services. Visualization is a class of analysis services that represent data within a presentation context subject to Investigator actor instructions. Workflow services define, modify, and manage processes that link resources and users to accomplish a goal. Modeling services utilize data and the modeling framework to generate data products for interpretation. They may operate open loop or may modify the observation protocols in a closed loop manner. Coordination services provide the capability to link resources within a policy management framework. Collaboration services support the tools needed to connect and manage multiple instantiations of the Observatory Network Model. Storage is the physical resource that contains archived data. Repository services provide data persistence and retrieval functions subject to governance constraints, including registration of data with the Catalog, subscription to corresponding data streams, and publication of data in response to requests from resources and users. Catalog services describe resources, containing their descriptors and associations, and may exist at many levels and locales within an ocean observatory. Distributed catalogs have a federated relationship and provide an organizational and policy management link

for transactions between resources and activities. Computing resources provide machine cycles to execute code at distributed locations for modeling and other purposes. Networking encompasses the resources needed to transmit messages. Communication services provide message delivery with different quality of service characteristics. Security services implement authentication, authorization, and auditing for all resources and users. Governance defines the policy management framework that is implemented throughout the cyberinfrastructure.

1.4.2 Instrument Node The Instrument operational node performs instrument management, mission execution, and other data acquisition tasks, and may include diverse sensor, actuator and mobile platform entities at multiple, dispersed physical locations. Figure 2 shows an expanded view of this node.

The instrument (science or engineering) device model consists of one or more physical sensors or actuators and a logical device that is typically implemented in firmware or software. The physical device provides sensor data and status information to the logical device, and receives configuration information and commands from the logical device. The physical device may also receive resource allocations (primarily bandwidth and power) from the observatory physical node to which it is attached. The logical device provides resource requests (primarily for power and bandwidth) to the observatory physical node and instrument data and status information to the Observatory Management operational node. It receives instructions to define or modify instrument configuration and functionality from the Observatory Management node.

In addition to providing allocated resources to a physical device, the observatory physical node receives resource requests from logical devices that either result in allocation of resources if they

Figure 2. The Instrument operational node, including the device model

are locally available, or passing of the resource requests to the Observatory Management node if they are not. The Observatory Management node then provides an allocation of resources to the observatory physical node once they are available.

1.4.3 Observatory Management Node The Observatory Management operational node performs monitoring and management functions for the remaining operational nodes subject to governance and policy constraints. Figure 3 expands its internal components.

The central element in the Observatory Management view is the Mission Control operational node that performs diverse resource management and allocation tasks and orchestrates the dynamic interplay of the Instrument operational node with the remaining nodes. The Mission Control node receives observation plans from the Mission Planning operational node, configuration and status information from the Science, Engineering, and Computational Subsystems, fault information from the Fault Detection and Identification node, and time from the GPS clock. It provides observatory and mission status information to the Knowledge Network and Mission Planning operational nodes, requirements and schedule information to the Science, Engineering, and Computational Subsystems, and control and management information

Figure 3. The Observatory Management operational node

to the Instrument operational node for direct transmission to instruments. The dual paths from the Mission Control node to the Instrument node (direct and via the Science Subsystem) represent the distinction between dedicated and shared instrument operation modes. In the latter, a higher degree of coordination and scheduling is required to avoid resource conflicts.

The Data Acquisition node manages the flow of instrument data from the Instrument node. It receives sensor data from the Instrument node, and provides them to the Fault Detection and Identification node, which monitors all Instrument interactions for unanticipated sensor and operational metrics. The Science Subsystem and Data Distribution nodes manage the flow of science data from the Data Acquisition node to other operational nodes. The Science Subsystem receives science data from the Data Acquisition node, capacity (i.e., machine cycles) from the Computational Subsystem, and scheduling from the Mission Control node. It provides observations to the Data Distribution Node and configuration and status information to the Mission Control node. The Engineering Subsystem plays an analogous role to the Science subsystem for engineering data, providing infrastructure services such as power and bandwidth allocations, as well as monitoring of the physical environment around the elements of the Instrument node. It receives engineering data from the Data Acquisition node and schedule information from the Mission Control node. It provides allocations and configurations to the Instrument and configuration and status information to the Mission Control nodes. The Computational Subsystem provides the computational resources and services needed by the Science Subsystem and Data Distribution nodes and configuration information to the Mission Control node, and receives schedules from the Mission Control node.

The Data Distribution node receives observations from the Science Subsystem, capacity from the Computational Subsystem, and subscription and routing information from the Knowledge Network. It provides observations to the Observation Subscribers node, which in turn provides subscriptions for observations to the Knowledge Network.

1.4.4 Analysis and Synthesis Node The Analysis and Synthesis operational node provides the core services needed for the analysis of observations and their synthesis into conclusions and testable hypotheses. It interfaces to Investigator or Expert actors through the Interactive Analysis and Visualization Model described in the next subsection, and utilizes the Knowledge Network that represents the integrated experience of the Observatory Network coupled to catalog and repository services. Figure 4 contains an expanded view of the Analysis and Synthesis node.

The Investigator or Expert actor provides input, experience and oversight for analysis and synthesis activities using the Interactive Analysis and Visualization Model. While the actor is depicted as logically connected to the Knowledge Network node, in reality it also links to the QA/QC, Modeling, Event Detection and Classification, Hypothesis Generation, and Event Response nodes. The actors may be distinct for different nodes; for example, the Investigator who is central to Analysis and Synthesis may be a scientist or educator, while the Expert in QA/QC may be an engineer and the Expert in Event Detection and Classification may be an engineer or statistician. In each case, the actor provides specifications and rules, process definitions, and key decisions to and receives decision and hypothesis evaluation requests from the relevant node.

The Quality Assurance/Quality Control (QA/QC), Modeling Framework, Event Detection and Classification, Hypothesis Generation, and Event Response nodes represent archetypical activities carried out in an analysis and synthesis effort. In this context, the nodes are activity centers that may be either ongoing or one-time in form. They are linked to the Knowledge Network that provides oversight and decision services mediated by Investigator or Expert actors. The QA/QC node performs automated data quality control and requires interaction with an Expert actor when automated algorithms fail or need modification. The QA/QC node functions as a filter that receives observations from the Instrument Network and process specifications from the Knowledge Network. It provides qualified data to the Knowledge Network. While not shown in the figure, QA/QC may also be carried out on retrospective data contained in repositories as improved QA/QC algorithms are devised.

The Modeling Framework node hosts prognostic and retrospective numerical models of observed processes and events, usually involving assimilation of real-time or retrospective data from the Instrument operational node or repositories, respectively. It receives specifications to define numerical experiments along with qualified data from the Knowledge Network node. It may also receive real-time data that has not been subjected to QA/QC directly from the Instrument node. The Modeling Framework node publishes model products and their descriptors to which the Knowledge Network node subscribes. In terms of process, the Modeling Framework is only

Figure 4. The Analysis and Synthesis operational node

slightly changed from QA/QC or Event Detection and Classification. It differs in the magnitude and diversity of model products that are produced. These are both production and consumption resource-intensive, and as a consequence modeling tends to gravitate toward resource-rich environments.

The Event Detection and Classification node is analogous to the QA/QC node, operating as a filter on real-time or retrospective data to provide detected and classified events as a product. The Event Detection node receives process specifications to establish trigger conditions, definitions and patterns for events and qualified data or model products from the Knowledge Network node. It may also receive real-time data directly from the Instrument node. It provides topic-based identified events and patterns to the Knowledge Network node.

The Hypothesis Generation node evaluates detected events or patterns and formulates testable hypotheses that can be used to define new actions such as observation missions. It receives events and patterns from and provides hypotheses to the Knowledge Network node. The Event Response node provides automated and expert (i.e., usually involving actor intervention) review of events and processes that may result in responsive tasking or retasking of instrument and mobile resources. It subscribes to rules governing resource usage and information on processes and events from the Knowledge Network node. The Event Response node provides observation requests to the Mission Planner that define observation programs to be performed in response to events.

1.4.5 Interactive Analysis and Visualization Model The Interactive Analysis and Visualization Model defines the roles in and approach for analysis tasks, and heavily emphasizes the visualization interface. It interfaces to Investigator and Expert actors, and may have multiple instantiations within the Analysis and Synthesis nodes. Figure 5 shows a breakdown of the model. The main activities carried out within the Interactive Analysis and Visualization Model framework are analysis and visualization as depicted in the Analysis and Visualization Engine nodes. These connect to the Presentation Platform at the right and the Knowledge Network node at the left, and have strong interfaces to actors who provide expertise for both algorithm development and investigational purposes. The Interactive Analysis and Visualization Model is highly nonlinear, with strong feedback between and among its various elements. The Analysis Engine node harnesses computational resources to reduce, assimilate, and model data and produce data products for further analysis and interpretation, usually by one or more Investigator actors inside a laboratory. It receives analysis algorithms and data from the Knowledge Network node and analysis instructions from Investigator actors via the Presentation Platform node. It provides data products (e.g., process characterizations and correlations) to the Knowledge Network node and algorithm information and data products to the Visualization Engine node for representation to the Presentation Platform.

The Visualization Engine node provides the services to define, generate and manage visual representations of data and data products. It receives visualization paradigms from the Knowledge Network node, algorithm information and data products from the Analysis Engine node, and presentation context information for the specific Presentation Platform node in use. The Visualization Engine provides visualization context information to the Knowledge Network

node to discover an appropriate set of representation paradigms, and renders data product representations based on one of these paradigms to the Presentation Platform node.

The Presentation Platform is the interface between the cyberinfrastructure and an Investigator actor, and contains both software and hardware elements to support interactive visualization of data and data products. It provides instructions to the Analysis Engine to manage and control modeling and analysis processes, contextual information (e.g., geospatial bounds, view classification such as textual, 2D, 3D and display paradigm) to the Visualization Engine, and navigation and selection information to the Knowledge Network node to obtain resources and their descriptors. It receives data and model product representations from the Visualization Engine for display.

The two actors and nodes on the left contain the elements needed to define and modify analysis and visualization algorithms, both of which are strongly experience- and data-driven. The Analysis Expert actor authors or registers scientific, numerical and statistical algorithms through the Analysis Algorithm Development node, which in turn leverages the experience and use-case information contained in the Knowledge Network, and publishes analysis algorithms scoped to a Knowledge Network domain of applicability. The Visualization Expert actor authors or registers visualization algorithms through the Representation Paradigm Development node in the same manner as the Analysis Algorithm Development node. These two development nodes provide a means for Analysis and Visualization expertise to be retained independent of and shared across a

Figure 5. The Interactive Analysis and Visualization model

broad class of presentation contexts in a loosely coupled collaboration between the Investigator and Expert actors.

1.4.6 Mission Planning Node The Mission Planning node provides mission design functions for new observation programs, and is tightly linked to the Mission Control node within the Observatory Management operational node. Figure 6 breaks down its internal nodes.

The central elements of the Mission Planning node are the Planner node and the Mission Execution subsystem. The Planner reduces schedule and policy information from many sources and synthesizes observation program plans for the Instrument node. It receives policy from the Policy Repository node, definitions that provide a common vocabulary from the Observation and Activity Dictionary node, models for instrument behaviors from the Instrument Model Repository node, observation requests from the Analysis and Synthesis node, and information on operating constraints (e.g., availability) from the Information Network. The Planner produces new or revised observational plans to the Mission Execution subsystem.

Figure 6. The Mission Planning operational node

The Mission Execution subsystem turns the observation plans from the Planner node into specific instructions to groups of instruments and mobile platforms. The Scheduler node receives observation requests and plans from the Planner node and provides tasking to the Execution node. The Execution node also receives sensor data and instrument operating metrics from the Instrument Network. The Execution node provides command and control information to the Instrument node and task status information to the Planner node for use in mission modification. The Fault Monitoring node checks the command and control information from the Execution node and the sensor information from the Instrument Network for consistency, and provides fault information to the Mode Identifier node. This node also receives models of instrument behaviors from the Instrument Model Repository and fault trees from the Fault Recovery Repository node. It provides fault recovery tasking to the Execution node. The Policy Designer node turns ORION governance and policy constraints into observatory and instrument policy that is provided to the Policy Repository node. The Policy Repository serves instrument policy to the Planner node to constrain observation program planning and observatory policy to the Observation and Activity Designer node. The Observation and Activity Designer reconciles policy with instrument behavior. It receives policy from the Policy Repository node, instrument behavior models from the Instrument Model Repository node, and a standard vocabulary from the Observation and Activity Dictionary. It provides new vocabulary information or vocabulary updates to the Observation and Activity Dictionary node.

The Instrument Modeler node provides information on instrument behaviors furnished by the Provider actors in facilities. It provides instrument behavior models to the Instrument Model Repository and fault trees for instrument recovery to the Fault Recovery Repository.

1.4.7 Knowledge Network Node The Knowledge Network node facilitates the capture and dissemination of and interaction with the accumulated experience and understanding gained from the Observatory Network. Experience and understanding are typically realized as declarations of provenance and citation or statements of evaluation and correspondence. At its core, the Knowledge Network provides catalog and repository services to all of the main operational nodes defined in Figure 1, and links multiple instantiations of the Observatory Network model in the form of Observatories, Laboratories, Classrooms, and Facilities together into an overall observatory system. It is broken down in Figure 7. The Knowledge Network node consists of a meshed set of federated Catalogs and Repositories operating at different levels within and external to the overall observatory. Three levels are shown in Figure 7: 1) Local Catalogs and Repositories that exist within instances of Observatories, Laboratories, Facilities, and Classrooms, 2) ORION System Catalogs and Repositories that contain information on aggregated and shared resources, and 3) external catalogs and repositories belonging to non-ORION organizations. Each Catalog instance can be decomposed into two containers: an association fabric comprised of a mesh of relationship assertions between resource descriptors, and a cache of resources that are identified as the descriptive content appropriate for search. Each Repository instance is the container for the resources required in the corresponding set of Observatory Network instances, and provides storage and retrieval services.

An Observatory Access node is the portal by which the Knowledge Network is entered, and has many instances both within the other key operational nodes in Figures 1-6 and in Observatories, Laboratories, Classrooms, and Facilities. Each receives local resource references and associations from its Local Catalog and resources from its Local Repository. It provides shared resources to the System Repository and association assertions and queries to its Local Catalog. Each Local Catalog instance receives assertions and queries from an Observatory Access node instance, resource registration descriptors (metadata) from its corresponding Local Repository and exchanges federation agreements with the System Catalogs. It provides resource references and associations to the Observatory Access node and association replicants to the System Catalogs. Each Local Repository node exchanges local resources with Observatory Access nodes. It also provides resource replicants to the System Repositories and resource descriptors (metadata) to its corresponding Local Catalog.

The System Catalogs contain resource descriptors from all of the Local Catalog instances and any External Catalogs with which ORION has access agreements. They exchange federation agreements with and receive association replicants from many Local Catalogs. They also

Figure 7. The Knowledge Network operational node

exchange access agreements with and receive metadata from External Catalogs. The System Catalog receives resource registration descriptors (metadata) from the System Repositories.

The System Repositories receive resource replicants and shared resources from many Local Repository and Observatory Access instances, respectively. They publish ORION formatted resources to External Repositories and subscribe to resources from External Repositories, mediating them into ORION-standard formats and integrating them into the ORION collection.