|This page describes how observatories and their resources are managed and are structured.|
Observatory Management is the capability to operate and govern a marine facility (e.g. RSN, CGSN, EA organizations) and its resources. The facility applies Marine IOs' resource policies. Marine operators can define their own resource policies, and assign resource attributes that trigger the appropriate policies given the roles of the acting users.
In addition to the marine facilities, the OOINet architecture supports the concepts of defining "Virtual Observatories" with their own sets of users and policies, but sharing the underlying resources from marine facilities. The implementation of these concepts has been descoped.
For the purposes of the concepts on this page, we use the terms "observatory" and "marine facility" interchangeably, unless explicitly stated.
- Observatory Management Scenarios, developed at the CG OMC workshop September 2011
- Observatory Status and Events
See CIAD SA Sensing and Acquisition, section Decomposition.
The main objectives of observatory management are
- planning of observatory resources and deployments,
- command and control of observatory resources,
- and monitoring the state of health of observatory resources.
The diagram below shows how resources in an observatory are organized.
Figure 1. Observatory Resources and Associations (OV-1)
One of the primary functions of a marine facility (observatory) is to manage its sites. Sites are hierarchically structured named locations of the observatory. Sites fall into these categories:
- Geographical sites: Named location determined by a geographical area for a region of interest within the marine facility. Examples include "Coastal Pioneer Upstream Inshore". In OOINet these are represented by the resource types Observatory and Subsite. Note: In OOINet Releases 2 and 3, only Observatory is used for geographical sites and Subsite is never used.
- Device sites: Named location, potentially determined by a geographical location (stationary assets) or area (mobile assets), where physical assets of a defined characteristic can be deployed. OOINet resource types include PlatformSite and InstrumentSite. Note: In OOINet Releases 2 and 3, PlatformSite can have PlatformSite child sites to represent more sophisticated assemblies such as moorings.
Device sites identify observatory resources for physical deployments. They constrain the device model of deployed devices and provide a reference for a continuous flow of information from a defined site, independent of the different devices deployed at the site over time.
A platform site is an organizational representation of a series of platform devices in the same place in the observatory over time. Use Cases include obtaining a time series of data from a given 'platform site', where different platforms have occupied the site over time, or getting the current information for a given platform site without worrying about which individual platform occupies it. Also managing the characteristics of all devices deployed to that site as a consistent group.
As individual platform devices are swapped out operationally (e.g., replaced with their successor after a period of operations), this resource links all the information from all the platforms of that type/location, across all of those deployments. This if platform A(1) is replaced by A(2) and then A(3) at a particular location X, the PlatformSite-A-X captures the time series of data sets across the successive deployments.
The association between platform devices and platform sites is made as a function of time: Only one platform device be deployed on a platform site at any given time.
Use cases and associations are similar to the platform site case above.
Note: if instrument devices are assembled with a platform device into one unit, e.g. for a CG buoy deployment, the resources and their associations can only change in orchestrated ways, to reflect the assembly nature.
Certain Data Products are associated with marine devices, such as instruments and platforms. This includes the raw and parsed forms of the data acquired in (near) real-time from the devices.
In particular higher level science Data Products are associated with an observatory site rather than with a specific device (such as L1 and L2 data products). This means that when the device deployed at an observatory site is replaced during the regular refresh, a different device takes its place, but one DataProduct exists that contains all data for all deployments for that site. This requires that the model for that site remains the same.
A Deployment is an assignment of a device to a suitable observatory site for a defined period of time. Every such deployment is represented by a Deployment resource. The geospatial extent and the device model for this deployment are provided by the Site resource, the temporal extend and any deployment specific information is located within the Deployment resource.
The following types of Deployment exist:
- Remote platform deployment: Deployment of a fully assembled platform device with instruments on a mooring site
- Cabled node deployment: Deployment of a part of the RSN cable infrastructure, such as a secondary node
- Cabled instrument deployment: Deployment of an instrument device on an existing RSN cabled platform device
- Mobile asset deployment: Deployment of a mobile asset (glider, AUV) to a named observatory site.
Figures 1 and 2 show the associations of Deployment to the concepts of Device, Site. The actual associations may reflect the assembly nature of a device, e.g. to one platform and all assembled instrument devices, and their respective sites.
Figure 2 shows the abstract pattern that relates resources of the base types Device (the physical unit), Model (the class of unit), Site (the place in an observatory where devices are located), Deployment (an instance of a Device deployed on a Site), AgentDefinition (a type of device agent/driver), AgentInstance (configuration for a specific device agent instance)
Figure 2. Device-Model-Site Pattern (OV-7)
A Marine Facility is a type of Org, i.e. an independent domain of authority with member users and shared resources.
Marine Facilities contain Observatory resources (also called "Sites" or "Array Sites"). CG, EA and RSN are marine facilities in OOINet.
The Marine Facility is represented in the External Interfaces diagram. Marine Facilities govern resources such as instruments and platforms, by defining policy.
|While physical resources are shared in one Marine Facility exclusively, they may be also shared with a virtual observatory and Org. In this case, there may be two different sets of policy combined for the resources: the virtual observatory's policy and the actual resource policy as defined by the marine facility. There is a clear precedence of policy and command and control ability for the marine facility and its members compared to virtual observatories and their members.|
Marine or Integrated Observatory Operator creates a policy by describing a Contract using Clauses. The operator identifies the observatory asset to which the policy will be applied, and defines the policy which applies to the target asset. Finally, the policy is activated. The policy characterizes qualifications, privileges, and liabilities that may apply to the individual that wants privileges to the observatory asset. When the operator activates the policy .
When a user attempts an operation requiring privileges for the given resource (for example, wants to see the resource, or wants to make it publicly visible), the ION applies the relevant policy to determine whether to grant the privilege.
Either the privilege is granted, and the user accesses the target asset; or the privilege is not granted, and the user is denied access. When access is denied, the reasons for the denial (the relevant policies and roles) are presented.
The user may choose to request new asset control privileges or challenge the denial at this point, and then retry the operation.
Marine Facilities can also communicate with other marine facilities and negotiate for exchange of data based on policies. Each facility maintains its own set of assets, data sets and policies.
The following diagram shows the relationships between resources, policies, lifecycles, agents and other ION entities. There is also an illustration of how policies are managed in the Policy Management Service, distributed to or accessed by ION containers or agents and then executed locally or by the Policy Decision Service.
Figure 3. Resources and Facilities
The figure below shows an exemplar flow of lifecycle state changes for a number of related observatory resources
Figure. Resource lifecycle coordination for observatory resources
See also: Observatory Management Scenarios, developed at the OMC workshop September 2011