Skip to end of metadata
Go to start of metadata

Overview of "Qualify Instrument Interface" Use Case

Use Instrument Development Kit (or equivalent) to test instrument and/or driver.


Tip: Key Points
UC Priority= 4 or 5: Critical, is in R2
Only boldface steps are required
<#> before a step —> lower priority
(optional) —> run-time option

Related Jira Issues:   Open   •   All

Metadata

Refer to the Product Description and Product Description Release 2 pages for metadata definitions.

Actors Integrated Observatory Operator, Marine Asset Operator
References Instrument Development Kit
Uses UC.R2.05 Register and Connect Instrument
UC.R2.06 Command Instrument
UC.R2.07 Direct Instrument Access
UC.R2.13 Acquire Data From Instrument
Is Used By UC.R2.09 Activate Instrument Driver
Extends  
Is Extended By  
In Acceptance Scenarios AS.R2.02C Instrument Life Cycle Support, AS.R2.04C Instrument Experts Drive Core Instrument Operations
Technical Notes The Instrument Interface is the interface exercised by the driver when it talks to the instrument.
This qualification is performed on the driver software, and on each instrument instance.
By plan, the qualification of the Instrument Interface is performed by using the Instrument Development Kit.
Lead Team MI
Primary Service Instrument Development Kit
Version 2.3
UC Priority 4
UC Status Mapped + Ready
UX Exposure EUC

Summary

This information summarizes the Use Case functionality.

For the final qualification of a driver or instrument, the instrument must be connected to the Instrument Development Kit (or equivalent observatory system), which contains a released ION software reference version. Proper operation is confirmed by activating the instrument, issuing commands through the instrument agent/driver, receiving data, successfully establishing a direct link to the instrument, and shutting down the instrument.

All transactions of the final Qualification test are logged and archived for the software, and for each tested instrument.

See the Comments section within this scenario for information on the Instrument Development Kit.

Assumptions

  • The Instrument Development Kit is operational and is the basis for performing instrument interface testing. (Alternatively, an installation of the Integrated Observatory can be used for performing instrument testing.) We refer to the system being used for testing as the 'test system'.
  • The existing driver for the instrument is accessible to the test environment; either the test system knows how to go get it, or it has been loaded to the test system, or it comes with the instrument and is automatically downloaded when the instrument is connected.
  • The test system has the most recent agent/driver and other Integrated Observatory software necessary to perform all the tests.
  • The primary data outputs desired from the instrument are defined by the OOI science team in an instrument-related document, referred to here as the Data Product Specification.
  • The qualification of the Instrument Interface does not include the qualification of the Level 1 (or Level 2, if any) data transformations associated with this instrument.
  • The performance of this qualification for the first instrument may be performed manually, and for subsequent instrument instances of that class it can be scripted. (These test scripts should be discoverable by the Marine Asset Operators.)

Initial State

Instrument driver and agent are written, tested, and configured for this instrument.

Scenario for "Qualify Instrument Interface" Use Case

  1. The tester (Integrated Observatory Operator or Marine Asset Operator) connects the instrument to the test system, an Instrument Development Kit (IDK), or equivalent system that is running the a reference version of the Integrated Observatory software.
    1. See the summary for details about the Instrument Development Kit.
    2. The instrument should be automatically recognized if it, and the Integrated Observatory, have that capability. (Unlikely for Release 2.)
  2. Within the testing environment, the tester registers and activates the instrument.
  3. Successfully perform commands for instrument (acquire for use, enable data-taking, get data on command, receive data stream, disable data-taking).
    1. Should exercise the full command functionality of the Instrument Agent
    2. Should exercise the full monitoring functionality of the Instrument Agent
    3. May also include starting up and shutting down the instrument.
    4. Verify that all data specified by related data DPSs can be collected by instrument.
  4. Successfully perform direct access commands (establish direct access, communicate with instrument, and disable direct access).
    1. Ability to communicate directly may depend on third-party software (e.g., for binary commands).
  5. Manually confirm transaction log exists for the above transactions and save them for the record.
    1. Details of the location to save this log to are to be determined.
  6. Perform qualification test suite
    1. This checks the instrument agent/driver and the physical instrument
    2. The test suite is started manually and executes automatically
    3. All test logs from this test suite should be saved/archived.
  7. Associate test protocols and logs with the instrument or interface software being tested
    1. Successful passing of all steps is prerequisite for either driver commissioning or instrument activation, as appropriate.

Final State

Instrument interface has been qualified and evidence of the qualification has been logged.

Comments

These comments provide additional context (usually quite technical) for editors of the use case.

The Instrument Development Kit provides a software and future hardware environment to develop instrument agents and drivers. It satisfies all the observatory and platform interfaces in a stand-alone deployment, provides user interfaces to test and operate instrument agents, and provides a qualification test suite of tests that all instrument agents/drivers have to pass to be accepted by OOI. Provisions exist to mimic observatory-specific infrastructure (including CG platforms in various configurations, CG intermittent connectivity, and RSN cabled deployment).

(click on # to go to R2 use case)
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
61     27B

Labels

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