Bring driver for an instrument model from conception through decommissioning.
|Actors||Integrated Observatory Operator, Marine Asset Operator, Integrated Observatory Manager, System Process Developer|
|References||CIAD COI OV Resource Lifecycle|
|Is Used By||UC.R2.08 Manage Instrument Lifecycle, AS.R2.04C Instrument Experts Drive Core Instrument Operations|
|Is Extended By|
|In Acceptance Scenarios||AS.R2.02C Instrument Life Cycle Support|
|Technical Notes||While many of the instrument driver's life cycle activities are performed offline, the instrument driver is a resource of the system and is registered and managed just like other resources.|
|Primary Service||Instrument Activation Services|
|UC Status||Mapped + Ready|
This information summarizes the Use Case functionality.
Bring driver for a specific instrument type from conception through decommissioning. Includes association with instrument type definitions, development, test, configuration and deployment of instrument drivers within instrument agents.
- An instrument has been identified for inclusion in the CI, meaning that a driver and associated basic data transformations will be built for it.
- For OOI-provided instruments, there are 3 authoritative (but modifiable) Sensor Sets, with instrument classes in each. The exact instrument model(s) chosen for a instrument class is determined through a procurement process.
- Externally provided instruments may be introduced by anyone, subject to conformance to OOI policies and interfaces; this is not an R2 concern.
- Instrument driver development is assigned to a developer.
- The actual instrument may be provided to the developer, but in many cases (e.g., where the sensor's size or operation prevents delivering the unit to the developer, or where it is convenient to support development remotely) the instrument is installed remotely in an operating configuration. In that case the developer is given remote access.
- The primary data outputs desired from the instrument, and the calibrations and other inputs needed to produce Level 1 science data, are defined by the OOI science team in a separate document, the Data Product Specification (DPS). (This used to be the Sensor Algorithm Theoretical Basic Document (ATBD).)
- OL representatives have verified that the instrument can be safely deployed, according to an OL-defined process, independent of the implementation of the driver software.
A specific instrument model has been identified and work is set to begin.
describes the corresponding resource lifecycle activity, and is not normative.
The steps do not involve the Integrated Observatory, and so are not normative.
- The System Process Developer characterizes the instrument and specifies a driver design based on the instrument agent/driver framework.
- Primary objectives for the driver functionality will be driven by the interface of the relevant agent, and the DPSs that use it.
- The developer may seek input from the OOI science community, the instrument provider or manufacturer, and potential operators or users.
- Ultimately, the developer finalizes the data outputs and device features the driver will provide access to. These are made available for review and comment by the OOI science community, and are approved by the CI Marine Integration Senior Developer.
- The System Process Developer implements the driver by assembling existing elements from the framework and developing code unique to the target sensor.
- Development follows a specific flow of modifying aspects of the driver design pattern. For example, if the sensor provides data in a streaming mode, the developer would step through the aspects of the state machine where received data is announced, parsed, then published.
- The System Process Developer tests the driver using an instrument on a local or remote testbed.
- In practice, testing occurs concurrently and iteratively with driver implementation. If the driver is determined to have defects or deficiencies, the developer returns to the implementation step or revisits the agreed data outputs and device features (changes must be reviewed following the original process).
- The development activity is complete when the driver is determined to meet the defined data outputs and features.
- The System Process Developer registers the completed driver in the Integrated Observatory.
- A UI may or may not be provided for this registration.
- The registration process may guide the developer to submit the required instrument characterization.
- Instruments can be registered to serve as data providers.
- <3> An appropriate member of the CI team validates resource usability and activates it in the Integrated Observatory system.
- The appropriate member likely needs to be an Integrated Observatory Operator (this will be determined later).
- Confirmation includes validation of the driver's correct operation with an actual instrument in an integrated system. (In-situ verification of instrument performance is included when possible.)
- The activation is likely to be represented/implemented by the transition of the resource's life cycle state (e.g., to Integrated).
- The CI development team will establish a permanent testbed for use in offline daily-build testing; only currently implemented drivers are tested with daily builds.
- <3> The driver is advertised as a system resource.
- The Integrated Observatory system may take this step automatically, based on the previous step's completion.
- A system-internal process certifies that the announcement is valid (or it flags an error to the provider).
- A system-internal process advertises the resource registration in the appropriate catalog and the announcement is propagated throughout the system.
- A system-internal process may publish a formal announcement of driver readiness.
- <3> The driver is made available for application by any Observatory Operator.
- Use includes discovery and association, including association with specific instruments as they are installed.
- This lets the instrument provider use the instrument with that driver.
- An Observatory Operator associates the driver with a specific instrument.
- This makes it possible to instantiate an instrument agent for the specific instrument and begin communicating with the instrument.
- The instantiation of the instrument agent with the driver/instrument is not described in this scenario.
- May be a developer acting in place of an observatory operator.
- <3> An Integrated Observatory Operator determines that a driver should no longer be available and disables its use by the Integrated Observatory system.
- In deactivating a resource, the provider must assess the appropriateness, costs, and user expectations of using that resource.
- One reason for deactivating a driver temporarily is that it is not appropriate to use (e.g., risking the instrument) until a bug fix is made.
- Deactivation is a necessary precursor step when the driver is to be decommissioned.
- A driver that is being replaced should be deactivated only after the replacement driver has been activated and the instrument can be associated with it.
- <3> The Integrated Observatory Manager determines that the driver should no longer be used at all, and effectively removes it from the system.
- The driver will no longer be available for use although its activation history and past associations will remain accessible.
- A driver is decommissioned when, for instance, it has been replaced by a more current driver. (Reactivation is possible at a later date, but awkward.)
- Before decommissioning, any instruments using the driver should be identified by the system and flagged to the Cyber Manager, as these instruments will no longer be functional without the commissioned driver. This test would be skipped if the deactivation is simultaneous with the successful Activation of a new driver.
The driver is in use, or has been removed from the system and decommissioned.
Some instruments behave and communicate similarly to others and a decision can be made to enhance an existing driver or develop an entirely separate but still similar new driver. For example, a Garmin GPS and an Ashtech GPS both provide standard NMEA0183 output sentences.
- Each manufacturer has unique output sentences not possible in the other's device. If this were the only difference, clearly both devices could share the same driver; when run on a Garmin the driver would simply never parse an Ashtech-only sentence and vice versa.
- Ashtech and Garmin each use their own proprietary method for configuration and changing parameters. In this case, the developer must make the decision based on the differences in communications whether the driver requires enough enhancement to be developed into a unique, separate driver.