Skip to end of metadata
Go to start of metadata

Guide on the use of this template

Purpose

This template is a direct result of Ocean Observatories Initiative (OOI) software developers, in an effort to reduce the burden on the Marine Implementing Organizations (IOs), trying to develop drivers as far as they can without Marine IO input; however, due to the nature of the Integrated Observatory Network (ION) System and the paradigm shift from every instrument being controlled by their own vendor provided software to an integrated observatory network it requires input from:  vendor, project scientist, engineer and other instrument experts to be able to develop an appropriate driver to support the scientific mission of the instrument.  ION is not a layer that sits on top of the vendor provided software.  It is a radical departure from and an expansion upon the traditional oceanographic method of the "fire and forget" method of instrument deployment and the isolated / stove piped method of a instrument relaying data back via its communication path to a single point without any dissemination.   ION is intended to make the oceanographic sensors much more dynamic scientific instrument tools.

This document is the result of discussions between CI, Marine IOs and Ocean Leadership (OL).  This document represents an augmentation to the existing Instrument Operational Specification (IOS) effort and defines some new sections, 3 in total, to extend the scope to instrument / node integration and deployment.  The item produced from this outline is for the sole purpose of allowing the efficient collection of required information from instrument experts (normally Marine IOs or OOI PMO) and transfer of that knowledge to CI for coding, implementation and/or operations. It is not sufficient for O&M maintenance or for use by scientists to exploit the data/products provided by OOI.

These IOSs provide the information for the installation, coding of any required software, integration and operation of all core instruments. The IOSs are complementary documents to the Data Product Specifications (DPSs), Node Operational Specifications (NOSs), ICDs and any other Cyberinfrastructure, OMS, OMC or O&M documents that pertain to deployed instruments.  In an effort to reduce duplication of information some of the information in this document is derived from the respective OOI instrument pages. 

OOI Instrument details are contained as child pages to [instruments:OOI Instruments].  OOI Instrument Operational Specification pages are child pages to the instrument detail pages.  Please update the individual instrument pages as appropriate.

Process

The process for completing this template is as follows:

  • Section 1 Instrument operational specification is elicited as early as possible.  The scheduling of meetings to elicit the operational characteristics of an instrument at a deployment site is driven by instrument procurement / availability / deployment date and meeting dates / priority are captured on the [OOI Instrument Operational Specification (IOS) Schedule] page.  These dates and priorities are subject to change based on instrument procurement  / availability / deployment changes.
    • An effort has been made to reduce the amount of work required at the Q&A by pre populating the template as much as possible with common / standard responses.
  • Section 2 Integration specification to be added later.
  • Section 3 Deployment specification to be added later.

Guidelines

  • This outline uses example text from the ???? IOS document.  This example text is in plain text formatting and is in blue font color.  All example text shall be replaced with information specific to the instrument you are writing or removed.  The example text shall be used as a guide to the format and content of the sections.  The font color shall be changed to black after your specific information is filled in.
  • <Italicized text within brackets is directions on how to fill out certain sections when example text and comments are not sufficient. After following the directions, delete these italicized portions from your specific document.>
  • Plain black text denotes parts of the document that are the same for all IOSs.  Plain text that is black should remain in the document and should not be changed.
  • Mark any section of this document that does not apply to the instrument you are describing with N/A.
  • Importance of completion- Sections with RED text are essential for initial design, coding and/or deployment/operations to begin. All the Sections are important and necessary for full operations. Focus on the Section headers in RED text.
  • Formatting:
    • There shall be no extra blank lines at the beginning or end of the text in each section.
    • The document title, page headers (same as document title), document number, version number, and data are changed ONLY through the Properties dialogue box under Advanced Properties. Once updated through the Properties dialogue box, right click on the field and select “Update Field”. DO NOT edit these fields manually within the document.

Section 1: Instrument Operational Characteristics

1  Introduction

1.1  Author Contact Information

<Primary contact information for the main author/curator of this IOS.>

Please contact Author Name (authorname@email.org) or the Instrument Operational Specification lead (IOS@lists.oceanobservatories.org) for more information concerning this document. You may also call the author at: xxx.xxx.xxxx

<Provide additional knowledgeable contact information if available- e.g., the marine engineer, a scientist that uses this make/model, even vendor contacts if they are willing.  Please make updates to this information on the appropriate instrument page (provided by the link in the “Page” column of the table).  The table below is derived from the individual instrument pages and updates should be made there as appropriate. Changes made to the instrument page will be reflected in the table below. >

PageScience ContactLogistics Contact

1.2  Metadata Information

<Purpose:  The ION system maintains metadata related to instruments and nodes.  This information is required for the MIOs and CI to know what fields to define and populate in the ION data sets. >

1.2.1  Instrument Name

<Give the 5-digit alphanumeric Class, the alphanumeric string Instrument Name, the Instrument Name/Measurement Description and the 3-digit alphanumeric Sensor Family, as currently listed in the OOI Data Products spreadsheet (DCN 1340-00000). >

The OOI Core Instrument Class for this instrument is (there may be more than one):

-        ???

The OOI Core Instrument Name for this instrument is (there may be more than one):

-        ???

The OOI Core Instrument Name/Measurement Description for this instrument is (there may be more than one):

-        ???

The OOI Core Sensor Family for this instrument is

-        ???

< Please make updates to this information on the appropriate instrument page (provided by the link in the “Page” column of the table).  The table below is derived from the individual instrument pages and updates should be made there as appropriate. Changes made to the instrument page will be reflected in the table below. >

PageInstrument FamilyInstrument ClassInstrument NameShort Description

1.2.2  Instrument-Specific Metadata

<This may include serial numbers if available, known history of deployments, unique “quirks” or issues with specific instruments, observed conditions under which the instrument seems to exceed required functionality or fails to meet expectations. Also include the list of metadata variables, engineering data or other items that should be captured in the metadata for this instrument.>

See Section 2 for additional instrument-specific metadata fields that must included.

PageInstrument ModelIO Part Number

1.3  Literature and Reference Documents

<Purpose:  To provide greater context to the instrument / platform that is outlined in this document.>

<Add any cited references in this section alphabetically by author’s last name.  All cited reference should also be saved as INSTRUMENT_AuthorLastName_Year.pdf files and posted to the OOI Document Management System (Alfresco) in the IOS Artifacts directory. Include a link or the file name with every reference.>

 

<Documents from Instrument manufacturers are stored on Alfresco under REFERENCE>>Instrument Reference. They should be referenced by their existing location/name. These are often referred to as the “manuals”>

PageWebsiteManuals

2  Instrument Specifications

<Purpose: This section provides essential information for first article driver development. The information elicited here is necessary for the OOI software developer to implement the required behaviors using the unique commands and operational characteristics of a specific instrument.  By using this information we can associate a driver code, and other operational information to a specific physical instrument. This is important to assure that the driver meets and satisfies the scientific needs expected of the instrument.>

2.1 Vendor

<Insert name of vendor, location of vendor, name (with email and phone number of vendor POC) here? If no commercial vendor, provide equivalent information for source of instrument>

PageInstrument Manufacturer

2.2 Model

<Insert instrument model here. If there are more than one, carefully list them and then carry the differences throughout the rest of this document.>

PageInstrument Model

Page Instrument Manufacturer Instrument Model Short Description
CTDBP-16
Seabird
Sea-Bird 16plusV2 (All Series) CTDs with a pump used on Near Surface Instrument Frames and MFNs/BEPs

<Insert an image of actual physical instrument.>

2.3 Firmware Version

<Insert instrument firmware version here. If there are more than one, carefully list them and then carry the differences throughout the rest of this document. >

Firmware
Deployment Configuration /
Additional Sensors Optode (DOSTA) 4831
Hardware Interface

2.4 Deployment Configuration and Interaction with other Sensors

<Describe the HW and SW configurations of the instrument on the various platforms. Include any other sensors to which this instrument may interfere or be affected. If such situations exist, propose mitigation steps for successful operations of all instruments (just not this one- i.e., “turn all others off and never use them.”)>

defines operation use for this instrument on this platform. If the instrument is used on multiple platforms, but is operationally very similar then we can use one template for both deployments.

< Please make updates to this information on the appropriate instrument page (provided by the link in the “Page” column of the table). The table below is derived from the individual instrument pages and updates should be made there as appropriate. Changes made to the instrument page will be reflected in the table below. >

PagePlatform

2.5 Preferred mode(s) of operation?

Are there multiple modes this instrument can operate in?  If so which is the preferred mode and do the different modes need to be implemented.  An example would be a SBE 19 which has a profiling mode that offers sub-second sampling rates and mooring mode which doesn't.  ADCP also offer several different operating modes, most of which won't be used and subsequently don't need to be implemented in the driver.

Uptime requirements – How much downtime/resetting is acceptable? Can auto-sampling be restarted easily/quickly?

2.6 Sample Time stamp / Clock Synchronization

<Purpose:  This section is used to determine how often to synchronize time and which time stamp to use for real time processing.  Also how does synchronization occur (e.g – at leading edge of next second, no preference).  There are  3 time stamps possible due to availability of different time synchronizations (i.e. - instrument, port agent & instrument agent).>

2.6.1 Instrument Clock

< Define the sync method and frequency. Add any quirks or issues with the internal clock.>
Questions to answer:

  • What is the instrument clock drift?
  • What is the clock precision?
  • What is the acceptable clock driver before sync?
  • When should the clock be synced?

2.6.2 Preferred Time stamp

< What is the preferred time stamp to use for the sample? All will be store, but one can be used for real-time transform processes. Timestamps can be supplied, if supported, by the instrument, serial server, and port agent.>

2.7 Sampling Procedure Needed for Driver

<Purpose:  This is not the same as sampling strategy.  >

<Insert sampling procedure here.  This is a higher-level description of how the instrument should be capable of sampling, e.g. – Polled mode, auto sample mode, and interval mode.  Other information about sampling can be included here if pertinent. For instance, a profiler auto sample should be uninterruptable during a mission. >

Polled mode

  • Polled (i.e. – the ability to request a single sample) is enabled for development if possible.

Auto sample mode

  • This mode represents the continuous and fastest (define rate) sampling the instrument can accommodate.

Bill F. – how IO will do sampling; i.e – polled interval, live in autosample, turn on pump / light / sample.

For example Mass spec: turn on, wait for warm up, etc.  Are the steps parameterized?

2.7.1 Sampling Procedure (high and low level)

Polled

Polled is enabled for development if possible.

Autosample

Do we want to implement auto sampling mode for this instrument.
Other information about sampling can be included here if pertinent. For instance, a profiler auto sample should be uninterruptable during a mission.

2.8 Instrument Risks / Damage potential

2.8.1 What is irreversible/unrecoverable?

2.8.2 Configuration churn – How often can configuration be read/written?

2.8.3 Resource limitations (reagents, wear/tear time (ie lamp on time), etc.)

2.8.4 Physical limitations (i.e. must be run in water)

2.9 Instrument INPUTs and OUTPUTs

<Purpose:  This section is to elicit the logical interface.  All physical and electromechanical interfaces are contained in the ICD.  This IOS only addresses the logical and software interface input and output.>

 

There can be different interfaces logical and hardware.  Protocol preferred and / or physical.

<INPUT: - Briefly describe the approach to providing operational INPUTS to the instrument. This can be approaches like serial, batch, command-at-a-time, at deployment only, etc.  >

<OUTPUT: - Briefly describe the types and means of output.  Indicate the data format that should be outputted[[t2]|#msocom_2]  _by the instrument. This should match the output format specified in the DPS. If there are multiple streams generated from this instrument they must all be listed here.   This would include things like: streaming, sample parsed, science data segregated from engineering data, interleaved multi-sensor per instrument. The goal is to provide the reader with a high level understanding of how and what comes off the instrument.  List stream names that the instrument driver should provide e.g. --“engineering_parameter stream” that outputs status of the instrument systems / health.  SeaBird instrument example provided below. >

<Note:  Parameters provided in the engineering_parameters stream represent the parameters marked “y” for output in the table column “Engineering Parameter” in the parameters table. >

<Note:  Range, resolution and units of data output.>

OutputFormat=0 (raw frequencies and voltages in Hex)

Data is output in the order listed, with no spaces or commas between parameters. Shown with each parameter is the number of digits, and how to

calculate the parameter from the data (use the decimal equivalent of the hex data in the equations).

1. Temperature A/D counts = tttttt

2. Conductivity frequency (Hz) = cccccc / 256

Streams

Raw

  • always published by default

engineering_parameters

  • name and value of any parameters marked as "engineering parameters"

status_hardware_data

  • parsed output from the GetHD command

status_calibration_coefficients

  • parsed output from the GetCC command

status_hardware_data

  • parsed output from the GetHD command.

status_calibration_coefficients

  • parsed output from the GetCC command.

< Indicate the data format that should be outputted by the instrument. This should match the output format specified in the DPS. If there are multiple streams generated from this instrument they must all be listed here. All raw instrument communications are streamed regardless of content. We only indicate streams that need to be parsed and used in ION downstream>


 [[t1]|#_msoanchor_1]TMc – check to see if ICD captures the logical and software interface as well.

 [[t2]|#_msoanchor_2]Range, resolution and units of data output.

2.9.1 Preferred instrument software interface

<Purpose: Some instruments provide multiple conduits for user interaction (e.g. - binary packets, ascii, menu driven, configuration file upload). In most cases this is an implementation detail in which "no preference" would suffice; however, there may be instances where an IO may prefer one method over another.>

<Specify the preferred software interface if any.  If none is preferred list "no preference".>

2.9.2 Output

Format

Indicate the data format that should be outputted by the instrument. This should match the output format specified in the DPS. If there are multiple streams generated from this instrument they must all be listed here.
All raw instrument communications are streamed regardless of content. We only indicate streams that need to be parsed and used in ION downstream.

2.9.2.1  Streams

raw
sample_parsed
engineering_parameters

name and value of any parameters marked as "engineering parameters"

2.9.2.2  Errors

Events to detect/alert
What to ignore (related to use cases?)
Interruptability – What operations can be interrupted when? What cannot be interrupted?

2.10  Parameters

<Purpose:  This section is intended to capture the instrument parameters and their default values to be used by the ION system to assure the instrument is in a known state upon startup or after direct access in the event a parameter is inadvertently changed. >

<These are derived from the instrument manual and represent instrument configuration items that are set at the startup of the instrument to assure the instrument is in a known state.  Insert all parameters from the instrument manual  SeaBird instrument example provided below. Indicate which parameters need to be supported, read only, default value, startup parameter, direct access and engineering.>

  • CI Implemented - Should support for this driver be built into the driver? This implies the ability to both get and set the parameter.
  • Read Only - Yes or no. If yes then only the get functionality will be implemented in the driver.
  • Default Value - Parameters can be set using a configuration file for the instance of the driver. If there should be a default value for a configuration value that can be used if the parameter is not explicitly specified in a configuration file it can be specified here. It is possible to have a parameter designated as read only and have a default parameter. This is a special case for a read only parameter that allows it to be set, but only with the default value. This is useful for static parameters that need to be set by the driver, but we don't want to expose functionality to the operator to change these values.
  • Startup Parameter - Yes or no. If yes then this parameter will be set when the driver starts up. Values are read from the driver configuration and if the parameter doesn't exist there the default value is used.
  • Direct Access Parameter - Yes or no. Similar to the startup parameter, but these are parameters that are set when the driver returns from direct access mode. The values of the parameter is configurable. It could be read from the configuration file or a snapshot can be taken prior to entering direct access mode. This decision is documented in the command section of this document.
  • Engineering Parameter - Yes or no. Yes indicates that the value of this parameter should be included in the default engineer output stream. Some instruments have commands that would dump parameters. In that case we may want to use the command instead of individually querying parameters as it may be more efficient. This can be described in more detail in the Status section of this document.

Add a column for min/max values from maual so driver can do range checking.

2.11  Command and Control list and possible responses

<Purpose:  This section is intended to capture the instrument atomic commands the instrument is capable of responding to.  These commands are used by the ION system at the lowest level; however, these commands will be abstracted to a higher level (see 3.11) for the marine observatory operator. >

<Insert or reference all commands to be sent to the instrument here. Include all possible responses from the instrument as a result of the commands and what actions should be taken as a result of these responses. Include or reference all messages/responses that may be produced by or generated from the instruments (regardless if associated with a command or not). Insert all parameters from the instrument manual.  SeaBird instrument example provided below. >

CI Needs to know specific characteristics for the driver:

• CI Implemented - Should support for this command be built into the driver?  The atomic command is all ways available from direct access.  This section determines what commands are available via the ION system.  Include commands that will support the stream definitions outlined in section xxx.

execute commands or operations. Which need to be supported? This can include logical commands, i.e. start autosample, poll, etc... and instrument specific commands, i.e. turn lamp on.
In this section we have found it useful to list all available commands in a table then indicate whether the command should be implemented by CI.

Any special issues (transactions, timing, combinations, patterns, delays, etc.)?

Define all command that the instrument supports.  It should also note whether CI should implement the command in the driver which means the functionality could be raised in the UX or used in other logical commands or transactions.  Usually this is listed in a table from with the command, ci implemented, and any notes.

2.12 Common Driver Commands

<Purpose:  This section is intended to capture the higher-level abstracted commands that the ION system will provide to the marine observatory operator. Listed below are the names of common driver commands that are implemented in all drivers.  In general these will be implemented using the atomic commands listed above (see section 3.10) and will not need to be modified.  However, if there is an action other than the standard set of commands used to perform the common driver command, e.g. – sync the clock after normal connecting to the instrument, list it below. >

< Common driver commands are commands available in all drivers. Generally these commands trigger instrument driver state transition while will be indicated in the nodes.>

CI Needs to know specific characteristics for the driver:

  • CI Modified – Represents whether CI should modify the common driver command to accommodate other actions.
  • Actions – Represents the added actions necessary for this instrument.
Common driver command are commands available in all drivers. Generally these commands trigger instrument driver state transition while will be indicated in the nodes.


Command CI Modified Actions Notes
connect no e.g.
Sync the clock
Connect happens when the instrument is initially connected to by the driver. This could be considered the initial power up. Final instrument state IDLE, ready to accept commands.
disconnect no   Describe anything that should happen before we disconnect or power down an instrument. Final instrument state STOP. This could be considered the driver shutdown.
discover no e.g.
If state change detected
  Enter command mode
  Apply startup parameters
  Enter auto sample mode
Is there any specific action that needs to happen before or after a state discovery. This can be constrained to only actions to take when a state discrepancy is detected (i.e. the driver reported state is different than the discovered state)
execute_acquire_sample no   Define any action to take before or after we manually take a sample. This command could potentially change instrument states. If there are any restrictions about changing instrument states (i.e. do not run if in auto sample mode) note them here.
execute_start_autosample no e.g.
Sync the clock
Set all startup parameteres
enter auto sample mode.
Describe any action to take before or after we transition into auto sample mode. Final state OBSERVATORY mode, synonymous with auto sample mode.
execute_stop_autosample no   Describe any action to take before or after we transition out of auto sample mode. Final state IDLE mode, read to accept other commands.
execute_test no   Describe the process to run an instrument test. This command could potentially change instrument states. If there are any restrictions about changing instrument states (i.e. do not run if in auto sample mode) note them here.
execute_calibrate no   Describe the process to calibrate the instrument. This command could potentially change instrument states. If there are any restrictions about changing instrument states (i.e. do not run if in auto sample mode) note them here.
execute_start_direct_access no e.g.
capture all direct acces parameters
capture the current state
enter direct access mode
Describe and actions to take before we enter direct access mode. (i.e. capture current configurations marked as "direct access parameters"). Final state, DIRECTACCESS.
execute_stop_direct_access no e.g.
restore all direct access parameters
sync time
change state to state prior to entering direct access
Describe any action to take after we exit direct access mode. (i.e. restore configuration snap shot).
execute_clock_sync no e.g.
time should be set on a second transition using a parameter because there is only single second precision.
Describe how we synchronize the instrument clock.
execute_acquire_status no e.g.
save current state
run all status command
gather all engineering parameters
return to store current state
Describe if there are any steps to take before or after
execute_reset no e.g.
set all startup parameters to what is stored in the instrument instance configuration or the default value if not specified in the config.
Default behavior is to send all startup configuration parameters. If this behavior needs to be changed indicate it here.

2.13  Instrument Specific Driver Commands

<List any commands to be appended to the Common Driver Command list here.  These are higher level abstracted instrument commands.  For example for a mass spectrometer “calibrate” would be a new >

<It is possible to create other methods in the driver that can be exposed in ION. For instance we may want a couple different methods that generate engineering data, the first runs in autosample mode and does not disturb data acquisition while another does a deep inspection of the instrument. We could implement the first in the standard execute_aquire_status method and a custom method, execute_deep_inspection, which runs more status commands and generates a report.>

2.14  Status

<In this section we need a table containing the names of the values to capture as engineering data and a description how we get the parameter.>

<If there is only one engineering stream we assume it is generated using the execute_aquire_status method. If multiple engineering streams need to be created custom methods will need to be created and the parameter list should indicate which method produces the parameter. >

<Engineering data can be polled on a configurable interval and streamed. >

It is possible to generate reports and associate the report with the instrument instance. This is useful for engineering data that doesn't need to be streamed on a regular basis.

2.15  Instrument health and safety items

<This may be a subset of the previous section. Include any and all commands to or messages from the instrument that may damage the instrument or platform. Include with these the default action (with appropriate command/action) to be taken and how quickly it needs to occur. Rank message/action on a scale from 1-3 with 3 meaning immediate danger and action required. A one (1) would be an advisory, low level message of a possible problem. Possible guidelines for value assignments are:

 

3: danger to the instrument requiring immediate intervention

2: threat to the instrument requiring intervention in the next XX hours (???)

1: advisory message providing information to the operator.

 

These values DO NOT relate to the value or accuracy of the instrument. They are strictly concerned with the health and protection of the instrument and platform.>

< Identify situations that may result in irreversible/unrecoverable damage. List constraints f operation (e.g., cannot be turned on unless in water)

2.16  Instrument/node engineering data- formats, descriptions, what to do with it

<Include or reference all non-“science” data that comes off the instrument here. Some of this may be already available from the related DPSs (and should be referenced rather than repeated). Indicate what of these data are needed for future product processing, quality control or for other reasons.>

<Be sure to include any time stamping points, formats and accuracies if possible. Include the preferred timestamp format and details – e.g., degree of precision>

2.17  Science data- formats, what to do with it

<Include or reference all “science” data that comes off the instrument here. Some of this may be already available from the related DPSs (and should be referenced rather than repeated). Indicate what of these data are needed for future product processing, quality control or for other reasons. Describe the format. This is the basic “science” data that comes off the instrument before any processing. It is sometimes called the “raw” data. Describe the format, frequency of occurrence (may be based on sampling strategy discussed above).>

2.18  Interfaces and any not contained in the ICD- that will be used

<Provide a link to the HW interfaces/ICD for this instrument.>

 

<If there are any interfaces (logical or physical- but mostly logical) that are NOT already captured in appropriate detail in any ICD or DPS, include them here. Include ONLY THE INTERFACES THAT WILL BE USED. We do NOT want to create volumes of documentation on features that are not relevant. It is OK to reference vendor manuals but it is NOT OK to simply say: “see manual”! The author MUST be specific in references to vendor manuals.>

2.18  Example code of drivers that others have developed/used

<Refer to an appendix that contains any and all examples of drivers for this instrument. We want to reuse as much as possible. Any language, and level of code comments may be useful. B balance providing something useful with spending three months looking for another example >

2.19 Tests used to qualify and accept Instrument Driver at Marine IOs

<Purpose: This information assures the completed driver is capable of supporting the instrument to meet the scientific expectations of the Marine IO.>
<Insert references to and/or the tests used at the procuring IOs to qualify and accept this instrument here. Be certain that there is traceability to the inputs and outputs of these tests so that they can be reused if necessary.> <This allows the implementing/deployment groups to both better understand the actions/commands/responses/output from the instrument and to possibly resue this knowledge in any driver developments, command and control procedures and operations>

<Are there any special acceptance tests that will be performed on this instrument that is noteworthy with regard to the driver. This may help the driver developer identify deficiencies in the requirements.>

2.20  Monitoring and Event Detection

While this document does describe event detection and monitoring of various configuration elements, they will not be implemented in the instrument driver and subsequently should not be part of the driver validation process. ION R2 will provide some monitoring processes and more will be delivered in R3.

This is a general admonision that the driver will not monitor parameters or be reactive to most instrument events. However, it is still seems like it might be useful to indicate some parameters that we may like to monitor.

2.21  Additional Instrument Information

Catch all to capture addition information regarding instrument quirks, errors, data, operations, procedures, special behaviors, uses, or other noteworthy characteristics of the instrument

Signature

Signature Page

Section 1, Instrument Operational Characteristics, has been reviewed and approved for release to Configuration Management.

OOI Senior Systems Engineer:                                                                             

                                        Date:                                                                             








This document has been reviewed and meets the needs of the OOI Cyberinfrastructure for the purpose of coding and implementation (if applicable).

        OOI CI Signing Authority:                                                                             

                                        Date:                                                                             


Section 2:  Integration Specification

To Do:  Incorporate integration specific sections of word document here.

Signature

Signature Page

Section 2, Integration Specification, has been reviewed and approved for release to Configuration Management.

OOI Senior Systems Engineer:                                                                             

                                        Date:                                                                             

This document has been reviewed and meets the needs of the OOI Cyberinfrastructure for the purpose of coding and implementation (if applicable).

        OOI CI Signing Authority:                                                                             

                                        Date:                                                                            

Section 3:  Deployment Specification

To Do:  Incorporate deployment specific sections of word document here.

Signature

Signature Page

Section 3, Deployment Specification, has been reviewed and approved for release to Configuration Management.

OOI Senior Systems Engineer:                                                                             

                                        Date:                                                                             

This document has been reviewed and meets the needs of the OOI Cyberinfrastructure for the purpose of coding and implementation (if applicable).

        OOI CI Signing Authority:                                                                             

                                        Date:                                                                            

Labels

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