iv_plan_ci_2011-05-11_v1-00

7/28/2019 IV_Plan_CI_2011-05-11_v1-00

1/17

R1 CI INTEGRATION ANDVERIFICATION PLAN

Version 1-00Document Control Number 1160-000002011-02-25

Consortium for Ocean Leadership1201 New York Ave NW, 4th Floor, Washington DC 20005

www.OceanLeadership.org

in Cooperation with

University of California, San DiegoUniversity of WashingtonWoods Hole Oceanographic InstitutionOregon State UniversityScripps Institution of Oceanography

2160-00001 R1 Integration and Verification Plan Version 1-00
http://www.oceanleadership.org/http://www.oceanleadership.org/

7/28/2019 IV_Plan_CI_2011-05-11_v1-00

2/17

Integration and Verification Plan

Document Control Sheet

Version Date Description Originator

1-00 5/11/2011 Draft for internal review A. Chave

1-10 5/18/2011 Candidate draft A. Chave

Approval Signature

This Integration and Verification Plan has been reviewed and approved for use.

Approval Authority Name (print): Tim AmpeApproval Authority Title: System Development ManagerApproval Authority Signature:Approval Date:

Approval Authority Name (print): Alan ChaveApproval Authority Title: Senior System EngineerApproval Authority Signature:Approval Date:

Approval Authority Name (print): Jack KleinertApproval Authority Title: QA ManagerApproval Authority Signature:Approval Date:

Approval Authority Name (print): Matthew ArrottApproval Authority Title: Project ManagerApproval Authority Signature:Approval Date:

Ver 1-00 1160-00000 i

7/28/2019 IV_Plan_CI_2011-05-11_v1-00

3/17

7/28/2019 IV_Plan_CI_2011-05-11_v1-00

4/17


1 Integration and Verification Overview

1.1 Purpose of Integration and Verification

This Integration and Verification Plan (IVP) applies to the Ocean Observatories Initiative(OOI) Cyberinfrastructure (CI) Implementing Organization (IO) for Release 1 (R1) that is dueto complete in July 2011. The IVP establishes the plans for CI I&V activities that precedeacceptance. Integration refers to the incremental aggregation of service components intoservice groups, service groups into subsystems, and subsystems into an integrated systemthat occurs during the Construction phase of the CI system life cycle. Verification refers totesting against the L4 requirements for the subsystems that occurs during the Transitionphase of the CI system life cycle.

1.2 Item(s) to be Integrated and Verified

During R1, the following five subsystems are under construction, and will be integrated andverified:

Common Operating InfrastructureCommon Execution InfrastructureData ManagementSensing and Acquisition (including Instrument and Platform Agent)External Observatory Integration

The L4 requirements are captured for each of them in modules with the same names, exceptthat the Instrument and Platform Agent requirements are in the L4 Marine CyberPoP-Network module.

The specific software elements that will be integrated and verified are captured in 2160-00002 R1 Integration Procedures and 2160-00003 R1 Verification Procedures documents.

1.3 Integration and Verification Objectives

Integration is the incremental aggregation of service components, service groups andsubsystems with increasing definition until a complete system is available. The objective ofintegration is ensuring that all internal and external interfaces are implemented correctly, andthat the outcome is functional software. This is divided into white box and black boxintegration, with the former combined with unit testing, and hence not addressed in this plan.Black box integration at the subsystem and system levels is covered by this plan, with thespecifics about what is integrated, how it is integrated and when it is integrated contained in2160-00001 R1 Integration Plan.

Verification is testing the integrated software to ensure its compliance with requirements, orin other words asks the question was the system built right?. For R1, verification occurs atthe level of subsystems or groups of subsystems once the integrated system is completeeven if a given requirement is implemented at the service component or service group level.For the CI, the L4 requirements are the focus of verification, as the L3 requirements areverified as rollups of the L4s.

Validation is a separate activity that confirms that the system meets user needs as built, or inother words asks the question was the right system built?. For R1, validation focuses onthe user workflows defined in 2130-00005 R1 Functional Design Specification and 2130-00006 R1 Functional Detail Specification, and will be carried out using the OOI acceptanceprocedures during the Transition phase of the CI system life cycle

Ver 1-08 1160-00000 1

7/28/2019 IV_Plan_CI_2011-05-11_v1-00

5/17


2 Reference Documents

2.1 General References

1100-00000 OOI System Engineering Management Plan version 3-141150-00000 OOI Test and Evaluation Strategy version 0-062010-00002 CI Quality Assurance/Quality Control Plan version 2-002110-000005 CI Integration, Test and Verification Strategy version 2-21

2.2 Specific Test References

1150-0100x R1 Acceptance Procedures2160-00001 R1 Integration Procedures2160-00002 R1 Verification Procedures

3 Integration and Verification Environment

3.1 Integration and Verification Location

All I&V activities will be carried out at Atkinson Hall, University of California at San Diegousing both the UCSD development and test environment and external provider resourceslocated in the cloud (e.g., Amazon EC2).

3.2 Environmental Constraints

None

4 Integration and Verification Methodology

Integration, and specifically black box integration at the subsystem level and higher, of R1

follows the standard approach of a bottom up approach, in which an increasingly complexseries of builds are integrated and tested. This methodology is documented in the IntegrationProcedure document. Integration is carried out during Construction.For R1, the following three verification methods will be utilized:

Inspection - examination of a software item against applicable documentation to confirmcompliance with requirements; for example, the requirement that a service component beextensible is evaluated by direct code and code documentation examination.

Demonstration the qualitative exhibition of functional or behavioral performance.Demonstration (a set of test activities with system inputs and conditions selected by thesystem developer) may be used to show that the dynamical response of a subsystem or

system is appropriate.

Test the quantitative exhibition of functional performance with known inputs and anexpected output that is usually not feasible when many interacting software elements areinvolved.

For R1, the only interface requirements to be verified occur in the External ObservatoryIntegration module, and focus on data formats.

Each requirement to be verified in R1 has been assigned to one of these three classes using

Ver 1-08 1160-00000 2

7/28/2019 IV_Plan_CI_2011-05-11_v1-00

6/17


the Verification Method attribute in DOORS. Verification procedures were then written by theSenior System Engineer, the I&T Team, and the Senior Developers. These will be executedduring Transition.

5 Integration and Verification Resources

5.1 Integration and Verification Materials and Equipment

5.1.1 Specialized Materials

None

5.1.2 Specialized Equipment

Integration is carried out using the UCSD software development and testenvironment documented athttps://confluence.oceanobservatories.org/display/CIDev/System+Development+Environment. This includes the programming environment, source code and versioncontrol, documentation procedures, unit testing including automated testing andreports, and the development environment.

Verification is carried out using the same hardware environment. In addition, someCommon Execution Infrastructure verification activities require the use of additionalresources located in the cloud, and are typically implemented using a commercialprovider such as Amazon EC2. Finally, verification of some of the Marine CyberPoP-Network requirements must include an exemplar instrument that, for R1, will be aSeabird CTD immersed in a bucket of water.

Additional equipment for integration and verification is limited to one or more laptopcomputers with a standard web browser.

5.1.3 Specialized Computer Hardware

See 5.1.2.

5.1.4 Software

The R1 software and its dependencies are documented athttps://spreadsheets.google.com/ccc?key=0AvOM5_fPfsmudGZmSXBoM2FwZzhzTzNra1JUcXJJRGc&hl=en&authkey=CM6MjOUI#gid=0

5.2 Integration and Verification Personnel

5.2.1 Integration and Verification Leads

Jamie Chen (Integration and Test Lead, UCSD)

Tim Ampe (System Development Manager, UCSD)Alan Chave (Senior System Engineer, WHOI)

5.2.2 Integration and Verification Conductor

Jamie Chen (Integration and Test Lead, UCSD)Roger Unwin (Integration and Test Developer, UCSD)

5.2.3 Other Participants

CI Management Team and Senior Developers as required

Ver 1-08 1160-00000 3
https://confluence.oceanobservatories.org/display/CIDev/System+Development+Environmenthttps://confluence.oceanobservatories.org/display/CIDev/System+Development+Environmenthttps://spreadsheets.google.com/ccc?key=0AvOM5_fPfsmudGZmSXBoM2FwZzhzTzNra1JUcXJJRGc&hl=en&authkey=CM6MjOUI#gid=0https://spreadsheets.google.com/ccc?key=0AvOM5_fPfsmudGZmSXBoM2FwZzhzTzNra1JUcXJJRGc&hl=en&authkey=CM6MjOUI#gid=0https://spreadsheets.google.com/ccc?key=0AvOM5_fPfsmudGZmSXBoM2FwZzhzTzNra1JUcXJJRGc&hl=en&authkey=CM6MjOUI#gid=0https://spreadsheets.google.com/ccc?key=0AvOM5_fPfsmudGZmSXBoM2FwZzhzTzNra1JUcXJJRGc&hl=en&authkey=CM6MjOUI#gid=0https://confluence.oceanobservatories.org/display/CIDev/System+Development+Environmenthttps://confluence.oceanobservatories.org/display/CIDev/System+Development+Environmenthttps://spreadsheets.google.com/ccc?key=0AvOM5_fPfsmudGZmSXBoM2FwZzhzTzNra1JUcXJJRGc&hl=en&authkey=CM6MjOUI#gid=0https://spreadsheets.google.com/ccc?key=0AvOM5_fPfsmudGZmSXBoM2FwZzhzTzNra1JUcXJJRGc&hl=en&authkey=CM6MjOUI#gid=0https://spreadsheets.google.com/ccc?key=0AvOM5_fPfsmudGZmSXBoM2FwZzhzTzNra1JUcXJJRGc&hl=en&authkey=CM6MjOUI#gid=0

7/28/2019 IV_Plan_CI_2011-05-11_v1-00

7/17


5.2.4 Cross-IO Participants

N/A

5.2.5 Witness(es)

Kathy Carr (OOI Requirements and Test Lead) at the discretion of the PMO

5.2.6 QA/QC

Jack Kleinert (QA Manager, Raytheon IIS)

5.2.7 Approval Authorities

Matthew Arrott (Project Manager, UCSD)

5.3 Input Data

Verification of requirements that require the input of a data set will utilize the USGS riversdata time series Connecticut River at Thompsonville, CT (network: NWIS, AgencyCode:USGS, SiteCode: 0118400) available from http://waterservices.usgs.gov/. They have beenconverted from WaterML1.1 to the OOI Common Data Model for internal CI use by code athttps://github.com/ooici-eoi/eoi-agents/blob/develop/src/net/ooici/eoi/datasetagent/impl/UsgsAgent.java

6 Data Collection and Analysis Plan

The Verification Procedures list the expected output for all tests and demonstrations. For R1,there is no expectation to ingest, persist or reproduce any extensive amounts of data.

7 Integration and Verification Schedule

7.1 Prerequisite Events

Successful completion of the Initial Operating Capability milestone review scheduled for May

25, 2011, is a prerequisite gateway that both validates the successful completion of anintegrated and tested release and serves as a Test Readiness Review for the verificationprocedures. The move from Construction to Transition cannot occur without completion ofthis milestone.

7.2 Planned Start Date

Integration is an ongoing activity during the third iteration of Construction that spansFebruary 14 through May 13, 2011.

Verification begins with the start of the Transition phase on May 30, 2011.

7.3 Expected Duration

The Transition phase spans 8 weeks.

8 Test Costs

Costs of integration and verification are consistent with those allocated to WBS number.

Ver 1-08 1160-00000 4
http://waterservices.usgs.gov/http://waterservices.usgs.gov/

7/28/2019 IV_Plan_CI_2011-05-11_v1-00

8/17


9 Safety Considerations

None

10 Environmental and Permitting Considerations

None

11 Requirements to be Verified

11.1 Table of Requirements

RQNumber

RQ Text Rationale & Description Verif.Meth.

TestProc

L4-CI-COI-RQ-46

The messaging framework shallprovide topic-basedcommunication.

Publish/subscribe mode isthe standard method ofcommunication in the OOI

T COI-2

L4-CI-COI-RQ-49

The messaging framework shallprovide store until requestedcommunication

Pull mode communicationrequires storage ofmessages until they arerequested

T COI-3

L4-CI-COI-RQ-50

The messaging framework shallprovide streamingcommunication

Streaming meansasynchronous, continuoustransmission

T COI-4

L4-CI-COI-RQ-53

The messaging framework shallprovide peer-to-peercommunication betweendistributed resources.

This includes resources onthe seafloor

T COI-5

L4-CI-COI-RQ-278

The presentation frameworkshall support HTML4-compliantbrowsers

D COI-6

L4-CI-COI-RQ-55

The presentation frameworkshall provide the web userinterface portlet building blocks

D COI-7

L4-CI-COI-RQ-279

The presentation frameworkshall be extensible

I COI-1

L4-CI-COI-RQ-58

The governance framework shallimplement a policy-baseddecision system for resourceaccess

The core capability tomanage resource access

T COI-8

L4-CI-COI-

RQ-280

The governance framework shall

provide policy enforcementservices

T COI-8

L4-CI-COI-RQ-281

The governance framework shallprovide policy decision services

T COI-8

L4-CI-COI-RQ-59

The governance framework shallenforce authorization ofresource access for actors

For actor to resourceinteractions

T COI-8

L4-CI-COI-RQ-61

The governance framework shallprovide different levels of accessfor actors or resources with

For example, access toinstrument managementrequires an additional

T COI-8

Ver 1-08 1160-00000 5

7/28/2019 IV_Plan_CI_2011-05-11_v1-00

9/17


different levels of authorization. authorization from access toits data stream

L4-CI-COI-RQ-285

The services framework shallenforce policy

T COI-8

L4-CI-COI-RQ-289

The distributed state servicesshall provide an attribute store

T COI-9

L4-CI-COI-RQ-290

The distributed state servicesshall be concurrent

T COI-10

L4-CI-COI-RQ-291

The distributed state servicesshall support multiple services

T COI-10

L4-CI-COI-RQ-292

The distributed state servicesshall provide consistent stateinformation across the OOInetwork

T COI-11

L4-CI-COI-RQ-342

The distributed state servicesshall manage state divergencevia branching

T COI-11

L4-CI-COI-RQ-74

The identity managementservices shall supportauthentication of all actors

accessing the OOI network

T COI-12

L4-CI-COI-RQ-77

The identity managementservices shall recognize identitycredentials issued by externaltrusted issuers

T COI-12

L4-CI-COI-RQ-80

The identity managementservices shall acceptauthentication tokens fromtrusted identity providers

The authentication tokencontains a persistent, non-reassignable identifier for theuser. Trusted identityproviders could becommercial entities likeVerisign or OOI memberinstitutions.

T COI-12

L4-CI-COI-RQ-85

The identity managementservices shall associate anyOOI-recognized entity with apersistent OOI identity.

T COI-12

L4-CI-COI-RQ-88

The identity managementservices shall require validatedcontact information for all actorsaccessing OOI resources

A minimum set of criteriamight include name,institution, phone and emailaddress

T COI-12

L4-CI-COI-RQ-89

The identity managementservices shall map the identityasserted by an identity providerin an authentication token to anOOI user identity

T COI-12

L4-CI-COI-RQ-330

A user interface to register actoridentities with the OOI shall beprovided

Access is restricted tospecified parties

D COI-13

L4-CI-COI-RQ-331

A user interface to authenticateactors shall be provided

D COI-14

L4-CI-COI-RQ-332

An identity registry to store theidentities of actors shall beprovided

T COI-12

L4-CI-COI- The identity registry shall T COI-12

Ver 1-08 1160-00000 6

7/28/2019 IV_Plan_CI_2011-05-11_v1-00

10/17


RQ-333 maintain the association of internal identities with externalidentities

L4-CI-COI-RQ-118

The resource catalog servicesshall manage information aboutall resources under CIgovernance

T COI-15

L4-CI-COI-RQ-119

The resource catalog servicesshall manage resourcemetadata

T COI-16

L4-CI-CEI-RQ-30

The elastic computing servicesshall execute virtual machinesindependent of the executionenvironment

This means that the processdefinitions are independentof the physical executionenvironment in which theyoperate. A virtualization layerensures that availablestorage and computationalresources are madeavailable to such processes.

D CEI-1

L4-CI-CEI-RQ-31

The elastic computing servicesshall schedule virtual machines

based on available executionresources

D CEI-2

L4-CI-CEI-RQ-32

The elastic computing servicesshall monitor executingprocesses

D CEI-3

L4-CI-CEI-RQ-33

The elastic computing servicesshall publish information aboutexecuting virtual machineinstances

D CEI-4

L4-CI-CEI-RQ-34

The elastic computing servicesshall dynamically add andremove execution resources tomeet demand subject to policy

D CEI-5

L4-CI-CEI-RQ-37

The elastic computing servicesshall utilize execution resourcessubject to policy

D CEI-6

L4-CI-CEI-RQ-46

The resource managementservices shall monitor statefulresources under CI governance

D CEI-7

L4-CI-CEI-RQ-47

The resource managementservices shall control taskableresources under CI governance

D CEI-8

L4-CI-CEI-RQ-50

The resource managementservice shall publish resourceattributes obtained by monitoringstateful resources

D CEI-7

L4-CI-CEI-RQ-85

The resource managementservices shall provisionexecution resources accordingto policy

D CEI-8

L4-CI-CEI-RQ-86

The resource managementservice shall manage executionresources according to policy

D CEI-8

L4-CI-CEI-RQ-105

The resource managementservices shall manage service

D CEI-9

Ver 1-08 1160-00000 7

7/28/2019 IV_Plan_CI_2011-05-11_v1-00

11/17


process definitions

L4-CI-CEI-RQ-106

The resource managementservices shall manage theinstantiation of serviceprocesses

D CEI-9

L4-CI-DM-RQ-32

The OOI-standard metadatamodel shall include a syntacticdescription for the content of aninformation resource

Syntax refers to thestructure, such as adefinition of the fields ina multi-column data set

I DM-1

L4-CI-DM-RQ-36

The OOI-standard metadatamodel shall include trackingof context

Context is informationabout resource usage,and might includelocation for a physicalresource or the modeland parameters for adata product

I DM-1

L4-CI-DM-RQ-40

The OOI-standard metadatamodel shall be extensible.

The model mustaccommodate newdescriptive information asneeded

I DM-1

L4-CI-DM-RQ-143

Internal data models shallbe capable of includingcoordinate data in scientificfeature types

Providing geospatial andtemporal coordinates is afundamental feature fordata access andoperations. Vertical (3D)coordinate conventionsare not yet widelysupported in the GIScommunity but arecritical to the Oceanscience community

I DM-1

L4-CI-DM-RQ-49

The internal data modelsshall be extensible

I DM-1

L4-CI-DM-RQ-149

The set of supportedexternal data file formatsshall include NetCDF Classic(3)

This format is soprevalent in thecommunity that it rises tothe level of arequirement. Seehttp://www.unidata.ucar.edu/software/netcdf/docs/netcdf/File-Format.html#File-Format

I DM-2

L4-CI-DM-RQ-145

Data shall be exportableusing the CF Conventions

The evolving CF MetadataConventions providecommunity agreementsfor representing

coordinate systems andcomparing physicalquantities. Althoughlimited in scope to certaindata models defined interms of netCDF, CF-compliance may beapplied to other syntacticformats, preserved in

T DM-5

Ver 1-08 1160-00000 8

7/28/2019 IV_Plan_CI_2011-05-11_v1-00

12/17


OPeNDAP access, andchecked automatically.Additions to CF can beproposed through a well-defined open communityprocess. Not all data setscan necessarily be madeto fit into this model. Seehttp://cf-pcmdi.llnl.gov/

L4-CI-DM-RQ-146

Data shall be ingestibleusing the CF Conventions tobuild an internal data model

If the external data setfollows the CFconventions, it should bestandard enough toimport into the internalown data model.

T DM-6

L4-CI-DM-RQ-148

The set of external data fileformats that can begenerated from an internaldata model shall beextensible

I DM-3

L4-CI-DM-RQ-151

The list of external datainterfaces through whichdata can be ingested into aninternal data model shall beextensible

New and evolving dataaccess protocol standardsin the community willrequire the OOI-CI toevolve as well

I DM-3

L4-CI-DM-RQ-152

The list of external datainterfaces through whichdata can be exported froman internal data model shallbe extensible

I DM-3

L4-CI-DM-RQ-153

The list of external datainterfaces shall include theOPeNDAP Data AccessProtocol V2

This protocol is soprevalent in thecommunity that it rises tothe level of arequirement. The CIshould keep up with thelatest developments inthe OPenDAP communitywhile still providingbackward compatibleprotocols for older clientapplications. Seehttp://opendap.org/faq/whatIsDods.html

T DM-5

L4-CI-DM-RQ-51

The dynamic datadistribution services shall

publish data fromdistributed data sources

This includes bothphysical resources and

data repositories

D DM-7

L4-CI-DM-RQ-52

The dynamic datadistribution services shallallow users to subscribe todata topics

This carries with it therequirement for aregistration service

D DM-7

L4-CI-DM-RQ-181

The dynamic datadistribution services shallimplement the definition of

This includes theimplementation of a topicfrom metadata

D DM-7

Ver 1-08 1160-00000 9

7/28/2019 IV_Plan_CI_2011-05-11_v1-00

13/17


data topics

L4-CI-DM-RQ-182

The dynamic datadistribution services shallsupport multiple datamessages on a given datastream

A data stream may carrydata messages from onedata source only, anyform of derived datamessages, subsets,aggregates or datamessages from multipledata sources,distinguishable bymessage attributes.

D DM-8

L4-CI-DM-RQ-180

The dynamic datadistribution services shallassociate data streams withdata resources

For example, if a realtime data stream has ahistoric record, asubscriber can reply thestream with a start timein the past, continuingwith new data as they aregenerated

D DM-8

L4-CI-DM-RQ-54

The dynamic datadistribution services shallprovide notification aboutdata topic change

This carries with it therequirement for anotification service andinterface

D DM-7

L4-CI-DM-RQ-130

A graphical user interface toregister for data topicsubscription shall beprovided

D DM-9

L4-CI-DM-RQ-131

A graphical user interface toregister for data topicnotification shall beprovided

D DM-9

L4-CI-DM-RQ-61

The data catalog servicesshall allow federation

Cataloging must notdepend on the location ofdata

D DM-10

L4-CI-DM-RQ-64

The data catalog serviceshall cross-reference OOIand external repositories

D DM-10

L4-CI-DM-RQ-136

The data catalog servicesshall cross-reference thedata catalog with theobservatory resourcecatalog

There should be one stopshopping for observatoryresources.

D DM-10

L4-CI-DM-RQ-132

The data catalog servicesshall permanently associatemetadata with all catalogeddata

T DM-11

L4-CI-DM-RQ-158

The data catalog servicesshall be capable of addingmetadata attributes

T DM-12

L4-CI-DM-RQ-159

A unique identifiermechanism for identifyingdata sets shall be provided

Needs to include data setidentifier and versioncontrol

I DM-4

L4-CI-DM-RQ-160

A unique identifiermechanism for identifyingparts of data sets shall be

I DM-4

Ver 1-08 1160-00000 10

7/28/2019 IV_Plan_CI_2011-05-11_v1-00

14/17


provided

L4-CI-DM-RQ-161

The unique identifiermechanism for data setsshall include versionidentification capability

I DM-4

L4-CI-DM-RQ-70

The data discovery servicesshall be capable of content-based recognition

This entails therequirement to find datathrough keywords inthem

D DM-10

L4-CI-DM-RQ-162

A graphical user interfacefor data discovery shall beprovided

D DM-10

L4-CI-DM-RQ-183

The data ingestion servicesshall manage ingestion of adata set

Service to make sciencedata known to the DMsystem for subsequentstorage in a repositorywith metadata attachedand cross-referenced

T DM-13

L4-CI-DM-RQ-186

The data ingestion servicesshall be capable of linking totopics

T DM-14

L4-CI-DM-RQ-184

The data ingestion servicesshall be indifferent todelivery order

T DM-15

L4-CI-DM-RQ-188

The data ingestion servicesshall manage data streammetadata

T DM-16

L4-CI-DM-RQ-189

A user interface for theingestion services shall beprovided

D DM-17

L4-CI-DM-RQ-73

The metadata managementservices shall utilize thedefined vocabularies

This facilitates thetransformation ofproprietary metadata

formats into the OOIstandard

T DM-6

L4-CI-DM-RQ-77

The persistent archiveservices shall be dataformat agnostic

D DM-18

L4-CI-DM-RQ-79

The persistent archiveservices shall preserve allassociations between dataand metadata

T DM-19

L4-CI-DM-RQ-80

The persistent archiveservices shall ingest andintegrate data sets thatarrive out of order or in

overlapping parts

Data may arrive indifferent quantities atdifferent times. Forexample, mooring data

may be delivered in adecimated form in nearreal time, with the entiredata set appearing atannual service times. Thearchive services must becapable of connecting thedecimated and completedata sets, and integratingthem into a single

D DM-20

Ver 1-08 1160-00000 11

7/28/2019 IV_Plan_CI_2011-05-11_v1-00

15/17


archived data set

L4-CI-DM-RQ-82

The persistent archiveservices shall supportdistributed data repositories

D DM-21

L4-CI-DM-RQ-84

The persistent archiveservices shall support dataversioning

T DM-22

L4-CI-EOI-RQ-22

Each Dataset Agent shall bethe logical representation ofa specified externalobservatory

Dataset Agents must becustomized to theinterface and capabilitiesof a given externalobservatory andrepresent it to the CI,and/or vice versa

I EOI-1

L4-CI-EOI-RQ-43

The Dataset Agent shallregister a dataset from anexternal observatory withthe CI

Register as a data source.This presumes that theexternal observatoryalready has an internalidentity.

D EOI-3

L4-CI-EOI-RQ-23

The Dataset Agent shallacquire data from anexternal observatory

Using the data modelappropriate to a givenexternal observatory

D EOI-3

L4-CI-EOI-RQ-24

The Dataset Agent shallimplement poll mode datatransfer

Polling means that the DAdictates when data aretransferred.

D EOI-3

L4-CI-EOI-RQ-25

The Dataset Agent shallimplement push mode datatransfer

Push mode means thatthe originatingobservatory or OOIdictate when data aretransferred. For example,according to a timeschedule.

D EOI-3

L4-CI-EOI-RQ-26

The Dataset Agent shallacquire associatedmetadata for all datatransferred from an externalobservatory

D EOI-3

L4-CI-EOI-RQ-27

The Dataset Agent shalltransform the externalobservatory data model tothe OOI Common DataModel

D EOI-3

L4-CI-EOI-RQ-28

The Dataset Agent shalltransform the externalobservatory metadatamodel to the OOI CommonMetadata Model

D EOI-3

L4-CI-EOI-RQ-29

The Dataset Agent shallpublish data to theExchange

D EOI-3

L4-CI-EOI-RQ-30

The Dataset Agent shallpublish invariant metadatato the Exchange

D EOI-4

L4-CI-EOI- The Dataset Agent shall D EOI-5

Ver 1-08 1160-00000 12

7/28/2019 IV_Plan_CI_2011-05-11_v1-00

16/17


RQ-31 publish variant metadata tothe Exchange when changeoccurs

L4-CI-EOI-RQ-32

The Dataset Agent shallacquire externalobservatory statusinformation

Op/Nonop at a minimum,but additional informationabout internal status if itis available

D EOI-6

L4-CI-EOI-RQ-33

The Dataset Agent shallpublish external observatorystatus to the Exchange

D EOI-6

L4-CI-EOI-RQ-36

The Dataset Agent shallacquire commands from theExchange

Commands from the CI tothe DA

D EOI-3

L4-CI-EOI-RQ-46

The set of external data fileformats that can beingested into an internaldata model shall beextensible

This addresses the bitsand bytes on disk andhow they are arranged(NetCDF, HDF, GRIB etc).New and evolving datastandards in thecommunity will requirethe OOI-CI to evolve aswell

I EOI-2

L4-CI-EOI-RQ-41

The IOOS Dataset Agentshall process data thatconform with the UnidataCommon Data Model

D, Int EOI-7

L4-CI-EOI-RQ-42

The IOOS Dataset Agentshall process data thatconform to a describedASCII text model

D, Int EOI-8

L4-CI-SA-RQ-222

Control services for physicalresources shall be provided

D SA-6

L4-CI-SA-RQ-140

A user interface to thecontrol services for physicalresource control shall beprovided

D SA-6

L4-CI-IMP-RQ-35

Each Instrument Agent shallbe the logical representationof a specified physicalinstrument type

Instrument Agents mustbe customized to theinterface of a givensensor or actuator typeand represent ituniformly to the CI.

I SA-1

L4-CI-IMP-RQ-36

The Instrument Agent shallacquire data from a physicalor simulated instrument

T SA-2

L4-CI-IMP-RQ-53

The Instrument Agent shallimplement push mode dataacquisition

Push mode is used forsensors/actuators thatcan be scheduled tocollect dataautonomously so that theIA acquires thempassively

T SA-2

L4-CI-IMP-RQ-391

The Instrument Agent shallacquire metadata from aphysical instrument

This includes variant andinvariant metadata,presuming theinstrument maintains

T SA-3

Ver 1-08 1160-00000 13

7/28/2019 IV_Plan_CI_2011-05-11_v1-00

17/17


these internally

L4-CI-IMP-RQ-51

The Instrument Agent shalltranslate instrument-specificdata to OOI-specific formats

T SA-2

L4-CI-IMP-RQ-50

The Instrument Agent shallpublish data to theExchange

T SA-2

L4-CI-IMP-RQ-254

The Instrument Agent shallpublish instrumentmetadata to the Exchange

T SA-4

L4-CI-IMP-RQ-38

The Instrument Agent shallpublish variant metadatawhen change occurs

T SA-4

L4-CI-IMP-RQ-41

The Instrument Agent shallhandle instrument events

This covers eventsdetected by theinstrument, as opposedto those detected by theIA

T SA-2SA-5

L4-CI-IMP-RQ-43

The Instrument Agent shallmanage instrument state

T SA-4

L4-CI-IMP-RQ-37 The Instrument Agent shallacquire commands from theExchange

This could be commandsfrom the Platform Agentto the IA or some otherpart of the CI directly tothe IA, depending on thedeployment specifics.

T SA-5

L4-CI-IMP-RQ-39

The Instrument Agent shallissue commands to aphysical instrument

T SA-5

L4-CI-IMP-RQ-42

The Instrument Agent shalltranslate CI commands toinstrument-specificcommands

This could be commandsfrom the Platform Agentor from some part of theCI, depending on the

deployment specifics.

T SA-5

L4-CI-IMP-RQ-587

The Instrument Agent shalltimestamp data as they areacquired

T SA-2

Appendices

Ver 1-08 1160-00000 14