The Deployment resource is a first-class resource with lifecycle state that represents a deployment of instrument or a platform device at a determined geospatial and temporal location or area, and a determined site in the observatory. It is the resource that provides for operations and planning. Additionally, deployments provide a historical view of sites and devices for a marine facility.
|Do not confuse the DEPLOYED lifecycle maturity state with the Deployment resource. This resource is an organizing concept that users can apply to find data that has meaning within a particular location, context, or configuration of the data-producing entities, and implicitly the period of time for which that context occurred. The DEPLOYED state indicates a current condition for a device or other resource.|
The following lists the most important types of Deployments:
- Deployment of an assembled platform device with instruments, e.g. a CG mooring
- Examples: High Power Surface Mooring (CG, EA), Deep Profiler (RSN)
- Deployment of a cabled instrument device on an existing RSN cabled platform device
- Examples: OBSSP instrument deployed on LV JBox
- Deployment of a cabled platform or node on the RSN Cable
- Examples: LV JBox
- Deployment of a mobile asset (Glider, AUV)
Figure 1. Deployment Types, Resources and Associations (OV-7)
One site can hold up to one primary deployment of a device. The primary device at a site (indicated by a "hasDevice" association from site to device) is the device that delivers data for the site's data products. There can be more active deployments at one site, but only one can be primary. This is the case, for instance, for CG mooring deployments where 2 mooring assemblies can be in close proximity at one site, where the subsequent deployment is in preparation and calibration and the current deployment is primary until the subsequent one is declared to take over.
Setting a deployment to primary at a site is an operator action. The granularity is at the level of a Deployment resource, i.e. a platform or instrument assembly as described above. For RSN, instruments can be individually deployed and switched to primary. For CG this is only possible at the level of the top level platform assembly (e.g. the surface mooring with all components and instruments).
The figure below indicates the primary device at a site through dashed arrows. Subsequent deployments can be lined up (assembled) and switched to primary when ready.
Figure 2. Deployment as Primary (OV-7)
A deployment resource is created in the planning state to signify the intent to position devices at a specific location. The device that is associated in the deployment will usually be in the planned or developed lifecycle stage.
The deployment resource transitions to the integrated stage when the associated device is integrated. In the case of a platform device this means that all hosted instrument devices have been declared integrated and testing of the platform is complete. For a device instrument deployment, this signifies that bench testing is complete and the device is ready to be deployed to the host platform device.
Sites that are associated with platform device deployments will often already exist in the deployed state when deployment planning begins. This is because most site locations are already defined by the OOI project. Hoever, scenarios exit where a device is assigned to a new site temporarily, the case of reallocating a glider to a subsite is one such scenario. In this case a new site resource is created in the planned stage and connected to the deployment which represents the duration of that reallocation. The site resource lifecycle states transitions to integrated when it is assigned to the subsite. The glider or AUV device lifecycle states transitions to integrated when hosted instruments are connected and the testing is complete. At this point the associated deployment resource can transition to integrated. Before deployment processing can commence, the operator must transition the new site to deployed. Then the device is deployed via the deployment activation process.
At any time during the lifespan of a deployment resource, information such as operational plans or activity logs can be attached to the resource to provide additional context. These attachments can be tagged with keywords to facilitate location of information but other users.
A Deployment resource transitions to the deployed lifecycle state with the associated device. When the operator has completed testing the device on site he then activates the deployment. This process involves validating that the specified site supports the intended devices, assigns the device as primary to the site, transition the devices to the deployed lifecycle state and finally sets the lifecycle state of the deployment to deployed.
If transitioning any of the instruments fails policy checks then the events are published. The deployment resource does not transition to the deployed lifecycle state. THe operator can then address the issue and manually transition the device and deployment resources into the deployed state.
Subsequently, the operator may transfer the streams from the new device to the site data product. The site data product is a transform that provides the stream of data from the device currently assigned to the site. This product will, over time, be supplied by multiple devices but the deployment resource provides a means to track the provenance of the data product.
|Activation should also set the state of all devices to Deployed and if this fails, the deployment activation should fail.|
When the allocation of the devices which are deployed to a site ends, the operator deactivates the deployment. This processes removes the association of devices as primary devices at the site, sets the lifecycle state of all devices to integrated and retires the deployment resource as it has fulfilled its intent.
Disconnecting the data products from the devices from the site data product is a separate step that may not be carried out until a new deployment is activated at the site.