Skip to end of metadata
Go to start of metadata

Define Marine Observatory Policies

Define an observatory, define roles and policies, assign assets and their policies, begin operations.

Summary

Observatory life cycle and policy —-- Define an observatory, define roles and policies, assign assets and their policies, begin operations. Addresses the application of observatory policy to constrain operations of marine assets.

Review Status Ready for OOI Review
AS Priority 4
AS Version 3.1.1
Issues Status (Jira) OverviewAllUnresolved
Custom Issues Lists Marine IO ReviewMarine IO ProcessesCI IO Verify

The custom issue lists are as follows. They include both open tasks, and tasks marked as fixed.

  • Marine IO Review issues are called to the attention of the Marine IOs for their review.
  • Marine IO Processes issues are expected to require further consideration/understanding of the Marine IO processes.
  • CI IO Verify issues are generally resolved, but the resolution needs to be confirmed with appropriate CI experts.

Outline

Related Use Cases

Use Cases Mapped to This Scenario

The following Use Cases have been mapped to this Acceptance Test Scenario:

Use Cases Cited by This Scenario

This Acceptance Test Scenario cites the following Use Cases:

Key

This text style = background material
This text style = priority <3> (not required).

( ) Indicates footnoted material targeted for Release 3.
( ) Indicates footnoted material targeted for Release 4.
[MI] , [Ops] Provided by MI or Ops team (has no use case).
[NoUC] indicates material for which no Use Case exists.

Overview Diagram

Click on the thumbnail image to pop-up a full-width image, or see image on its own page.

Roles

Observatory Representative Owner (Default Observatory Manager) : This individual is the first responsible person in the observatory; as such, all permissions flow from this role. Usually serves to appoint an Observatory Manager.

Observatory Manager (Observatory Manager): An Observatory Operator who has been granted privileges to manage and modify observatory settings and properties. Can create and share an observatory.

Integrated Observatory Operator (Integrated Observatory Operator): An Observatory Operator for the Integrated Observatory. Can manage user accounts, and schedule and manage OOI computational processes and resource allocations.

Observatory Operator (Observatory Operator): A Registered User who has been granted privileges to manage and modify all observatory resources. Can create, manage and share observatory resources, and register external sources

End-to-End Scenario

Relevant Use Cases
Material from relevant source use cases is presented in a box with prefixes like this. Each reference can be expanded.
CG.OMC.nn — OMC use case
CG.WS-SC.n.n.n — CGSN OMC workshop notes (scenario number)
CI.UC.nn — CI Release 2 Use Case
CI.CO.n.n — CI Instrument Life Cycle Operational Concept, Version 1-00, 2115-00001, 10/28/2008

Create observatory and add assets

Relevant Use Cases
UC.R2.11 --- Define Marine Observatory Resources and Policy
UC.R2.33 --- Enroll in an Org
UC.R2.36 --- Create an Org
UC.R2.38 --- Define and Use Resource Life Cycle

A marine observatory has been created as a resource on the Integrated Observatory system. The representative owner of the observatory, John-Bob, has provided the key information as to the observatory's name (Enduring Pioneering Observatory, or EPO) and manager (himself). This resource is a facility of the Integrated Observatory, and as such inherits many roles and policies from that system. ( 1 ) ( 2 )

In principle the Observatory Representative Owner requests the assignment to his role so he can create the observatory, but in the absence of the observatory, there is no higher-level authority to grant that role, and no observatory within which to occupy it. So as a bootstrapping matter, the Integrated Observatory Operator will create the observatory and anoint John-Bob as the Representative Owner. (See UC.R2.36 Create an Org.)

John-Bob is eager to delegate all the work to an Observatory Manager, Louise. He issues an invitation to Louise (who could have requested the role, as a way to initiate this negotiation, but was too busy; in that case John-Bob would have approved the request, which would have initiated the same invitation). Louise sees the invitation and accepts it, and so is granted Observatory Manager privileges. (As the Representative Owner John-Bob has all Observatory Manager privileges as well; as Observatory Manager, they both have all Observatory Operator privileges also.) (See UC.R2.33 Enroll in an Org.)

The Observatory Operator (Louise in the inherited role) uses the Integrated Observatory system to add marine assets and other resources to the observatory, following the direction of any higher level authorities. Marine assets include platforms and instruments; other resources that are needed may be more abstract, like sites and policies. The Integrated Observatory software enables this new Enduring Pioneer Observatory facility to provide integrated management of these assets throughout their lifecycle, including their creation, configuration, test and use. (See UC.R2.11 Define Marine Observatory Resources and Policy.)

The Observatory Operator performs registration operations on many types of assets. An Observatory Operator by default has permission to perform all registration operations, though this authority could be narrowed by the Observatory Manager, who controls the observatory settings. These operations include activities such as register an instrument, register a user, and register a data producer.

The Operator provides the information about each asset in a series of steps, using UI screens that guide the collection of relevant metadata, including configuration and provenance information. Registering a complex instrument and its data products may require significant time to complete. Existing contextual information about the observatory, user, and the asset type allow many fields to be pre-populated; for example, many instrument models are shared across the OOI, and registering an instrument of that model can reuse the existing model definition.

When the Operator has completed the registration workflow, the Observatory finalizes each asset's registration by creating the internal representation and appropriate associations. These associations allow the asset to be located, viewed, and retrieved in various observatory dashboards and views.

The user is notified of any errors that occur. These may reflect invalid or conflicting information, permissions issues, or other errors in completion of the registration. The operator can take corrective action and attempt to register again.

The Integrated Observatory sets the initial lifecycle state for the resource, depending on the type of the asset. (Some physical assets are assumed to start out in 'Planned' state, while other digital assets are assumed to be operational ('Deployed') as soon as they are created.) The Observatory Operator may be able to modify the life cycle state, depending on the asset type. (See UC.R2.38 Define and Use Resource Life Cycle.)

When the registration completes successfully, the Observatory Operator will be notified and the new asset will appear in appropriate views of the observatory.

Once the resource is activated, the Operator will be able to interact with the asset such as running calibration tests on an instrument or setting the visibility level for a data resource.

Future Release Notes
Release 3

Define observatory-specific roles

The Observatory Operator can add a role for this observatory, by duplicating an existing role in the Integrated Observatory and then constraining it. The new role will inherit all the restrictions and capabilities of the original ION role on which it is based. The Observatory Operator can add restrictions or subtract capabilities, but can not create a more powerful version of the role than the ION system supports.

Subsequently, this new role may be granted permission to use various activities or resources inside the Integrated Observatory, in addition to the capabilities described for the Marine Observatory. This is a policy decision on the part of the Integrated Observatory.

Role assignment may include precursor conditions, such as certifications (training programs completed, evaluations or screening results), experience (with equipment or in other roles), or approval from senior staff.( 1 ) most will be evaluated outside of the software realm.

Because the definition of a new role is likely to require editing of specification files (e.g., in XML), the Integrated Observatory Operators may assist in the definition of new roles. ( 2 ) Metadata must be entered about the role, including its name and description. ( 3 )

Assuming the observatory has been activated, when the required information is completed and the role has been successfully registered within the system, the operator may activate the role so that it may now be offered to users operationally. (This operational activity optionally begins with a user request, continues with the issuance of an invitation, and concludes with the acceptance or rejection by the invitee, as illustrated in the last section.)

Future Release Notes
Release 3

Define observatory-specific policies

Relevant Use Cases
UC.R2.11 --- Define Marine Observatory Resources and Policy
UC.R2.42 --- Define Resource Policy

A Policy is a named set of statements governing the relationship between two resource types, specifying what capabilities are granted to a resource type (the Subject resource) when interacting with another resource type (the Target resource). Each policy contains

  • A set of statements that qualify, or specify, zero or more possible Subject resources
  • A set of statements that qualify, or specify, any possible Target resources
  • A set of statements that identify the capabilities the Subject can perform with respect to the Target. Each statement specifies a different capability; for a given set of constrained Subject and Target resources, all the presented capabilities are available (see example).

(In architectural language, an Observatory Operator creates a policy by describing a Contract using Clauses (see Governance Model reference).)

The Observatory Operator identifies the subject resources which will benefit from the policy, the observatory target resource(s) to which the policy will be applied, and (from a constrained selection) the policy which relates the subject resource(s) to the target resource(s). ( 1 ) (See UC.R2.11 Define Marine Observatory Resources and Policy.)

The policy characterizes qualifications, privileges, and liabilities that may apply to the individual that wants privileges to the observatory asset.

The Observatory Operator activates the policy (which takes effect when the observatory is activated; if the observatory is already activated, the policy takes effect immediately).

When a Principal — for example, any 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 Integrated Observatory applies the relevant policy to determine whether to grant the privilege. (See UC.R2.42 Define Resource Policy.)

  • 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 at this point, and then retry the operation.
  • ( 1 )

For example, the following specification creates a policy that can be read as "Any user who is a member of CGSN organization and has a CGSN Role of Instrument Operator can command through ION, directly command, or manage the lifecycle of any instrument owned by CGSN."

  • Subject: Resource type = User, Qualifying Rules = Is member of CGSN org & has CGSN Role of Instrument Operator
  • Target: Resource type = Instrument, Qualifying Rules = has owner CGSN
  • Capabilities: Command through ION; Direct command; Manage lifecycle
Future Release Notes
Release 3
Release 4

Assign people to roles

Relevant Use Cases
UC.R2.33 --- Enroll in an Org

Operators may grant roles to registered system users. For a given user, the Observatory Operator can select one ( 1 ) roles that are to be granted. The user will be notified — via an invitation — that he or she is being offered the role, with any specific agreements the user is agreeing to by accepting.

When the user accepts the invitation, he or she is assigned the role. The role will then appear as part of the user profile. (See UC.R2.33 Enroll in an Org.)

( 2 )

Future Release Notes
Release 3

Expose observatory definition

Relevant Use Cases
UC.R2.38 --- Define and Use Resource Life Cycle

During the configuration of the observatory, the observatory is by default not visible to other facilities or their members, including Integrated Observatory users. At any time, the definition of the observatory, including detailed description of all assets, policies and other features, may be exposed by the Observatory Manager. This makes the observatory visible. (See last two steps of UC.R2.38 Define and Use Resource Life Cycle.)

Activate observatory

Relevant Use Cases
UC.R2.26 --- Navigate Resources and Metadata
UC.R2.38 --- Define and Use Resource Life Cycle
UC.R2.58 --- Display Arbitrary Resource

Once an observatory has been defined by specifying assets, policies, role and other capabilities that comprise its domain, it must be activated to make it capable of operation.

The Observatory Manager may inspect the status of assets and other components of the observatories using the views provided in the UI. (See UC.R2.26 Navigate Resources and Metadata and UC.R2.58 Display Arbitrary Resource) Once satisfied that the definition is sufficiently complete, then the Observatory Manager can activate the observatory. If the Integrated Observatory is successful in completing the activation process, the state is reflected in the resulting views of the observatory. If activation fails, then reasons for the failure are displayed to allow the Observatory Manager to take corrective action. (See UC.R2.38 Define and Use Resource Life Cycle.)

Once the observatory has been activated, all of the assets and relationships defined for it are in effect and enforced by the Integrated Observatory Network.

Update observatory

Relevant Use Cases
UC.R2.26 --- Navigate Resources and Metadata
UC.R2.28 --- Manage Resource Metadata

The Observatory Operator may update observatory assets, policies, resource metadata, and other attributes of observatory resources as required to maintain an accurate definition of the observatory. The changes are tracked as revisions of those resources. (See UC.R2.28 Manage Resource Metadata.)

The Observatory Operator may view the effect of the changes to the attributes as soon as they are complete, and may navigate to related resources and metadata where it exists. (See UC.R2.26 Navigate Resources and Metadata.)

( 1 )

( 2 )

Future Release Notes
Release 3

Labels

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