Skip to end of metadata
Go to start of metadata

The goal of this refinement is to define the tasks will need to be accomplished in order for the interactions to be defined (i.e. the interfaces) between the various services that make up the Sensing and Acquisition Service Network and the other individual services that compose the other service networks. The only development work that should be included in these tasks are things that will be done to inform the process of pattern definition.

The Sensing and Acquisition Service Network is made up of the following services:

  1. Direct Instrument Access Service - This service provides direct IP connectivity between the research team and their instrumentation from anywhere within the integrated network. The service is designed to support instrument connections using telnet, ssh and/or proprietary instrument software. Such a channel has a higher-level security requirement, and initiation will require a separate and more stringent authentication process.
  2. Instrument Management Service - Provides the command, control, and monitoring services to operate and manage an instrument. Operating an instrument has a higher-level security requirement, and engagement will require a separate and more stringent authentication process. This service also supports instrument development and deployment through test and validation services.
  3. Instrument Repository Service - Maintains informational representations of instruments and their configuration and calibration, along with references to their acquired data.
  4. Data Process Repository Service - The data process repository service maintains copies of all processes applied to data from acquisition through product delivery. All are associated with their respective metadata.
  5. Data Acquistion Service - Provides services to configure data acquisition, disseminate and persistence of observed data originating from an Instrument platform to the Integrated Observatory Network

The services that the Sensing and Acquistion Service Network will interact with will be:

  1. Data Management Service Network
    1. Common Data and Metadata Model Service
    2. Data Exchange Service
    3. Data Catalog Service
    4. Persistent Archive Service
  2. Common Execution Environment
    1. Elastic Computing Service
    2. Execution Engine Catalog Service
    3. Resource Management Service
  3. Common Operating Infrastructure
    1. Federated Facility
    2. Messaging Service
    3. State Management Service
    4. Identity Management Service
    5. Policy Service
    6. Resource Catalog Service

If we look at these services in matrix form, we can define the interactions and dependencies between all the services:

SA Service Common Data & Metadata Model Data Exchange Data Catalog Persistent Archive Elastic Computing Execution Engine Resource Management Federated Facility Messaging State Management Identity Management Policy Resource Catalog
Direct Instrument Access

All interactions must be recorded for audit and traceability. This will most likely go to the data exchange.
No direct interactions per se, but the persistent archive needs to make all information available to other resources
All direct access communication will go through the messaging service
Any changes of state due to direct access will have to be propagated to the state management service
Messages need source and destination identities defined in them for routing
Requests through direct instrument access should be checked against policy.  For example, you don't want someone turning on a noise producer when doing acoustic monitoring.
Instrument Management All management interactions must be recorded for audit and traceability. This will most likely go to the data exchange.

No direct interactions per se, but the persistent archive needs to make all information available to other resources
Instrument Management would build on top of the resource management. It would include any interactions that apply to instrument resources (including instrument specific management tasks).
Part of the lifecycle of the instrument will have to be through interactions with the Federated Facility.  Enrollment and allocation are some examples.
All interactions for the Instrument Management service with other systems will be through the messaging service.
Any changes of state in the instrument due to management interactions will have to be propagated to the state management service
The instrument management service will have to ensure that messages are coming from a trusted identity.

The instrument management service will have an implicit trust relationship so will not interact directly with the policy service, but the policy service will be heavily involved in any interactions that manage instruments.
During the enrollment and allocation phase of the instrument lifecycle, the management service will have to push its resource information into the resource catalog service.
Instrument Repository This service will have to store instrument information in terms of the common data and metadata models.  This means translations will have to occur between the instrument information and the common models.
The instrument repository must inform the data repository of the information that describes the data generated by the instrument.  It will do this in terms of the common metadata and data models.

The repository must present the resource management service information from the instrument repository so that the resource management service will know what capabilities and states can be managed and how to manage them.
All interactions for the Instrument Repository service with other systems will be through the messaging service. The instrument repository service must inform the policy service of its capabilities to be governed and if there are any instrument specific policies.
The instrument repository is an extension of the resource catalog.  The catalog will contains the properties of the instrument that are common to all resources (things like ID).
Data Process Repository
The data processes that are being registered in the repository will need to be translated and described in the terms of the common data and metadata format.
The data process service will have to notify the data catalog of the semantics of the data that is generated by the data processes.
Any data processing in the elastic cloud will have to be described in the data process repository.
Most processes that are operating and are registered in the repository will certainly be tracked by the execution engine.
Any resources associated with data processes will have to be managed and so must describe the capabilities of the data process so that it can be managed by the resource manager
A data process that is in the repository will have gone through the enrollment phase of the federated facility.
All interactions for the Data Process Repository service with other systems will be through the messaging service. The state model for the processes in the repository must be registered with the state manager so that it can track data process state.
If there are any data process specific policies, those must be represented in the correct form and enforced in the policy service.
The data process repository will build up from the resource catalog.
Data Acquisition The data that is acquired by this service must be described (translated) into the common data and metadata forms.
All data acquired will be put into the data exchange.
The description of the data that is acquired must be stored in the data catalog.
The historical data that was acquired will be available through the persistent archival service.

The data acquisition process will need to be managed as a resource.

All interactions for Data Acquisition service (including data acquired) will be through the messaging service. The acquired data will have to be tagged with an identity.

The data acquisition process as well as the end data products will have to be registered in the catalog

Task List (PDF Version)

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.