R1 CI INTEGRATION AND VERIFICATION PLAN

Version 1-00 Document Control Number 1160-00000 2011-02-25

Consortium for Ocean Leadership 1201 New York Ave NW, 4th Floor, Washington DC 20005 www.OceanLeadership.org in Cooperation with University of California, San Diego University of Washington Woods Hole Oceanographic Institution Oregon State University Scripps Institution of Oceanography

2160-00001 R1 Integration and Verification Plan Version 1-00

Integration and Verification Plan Document Control Sheet Version 1-00 1-10 Date 5/11/2011 5/18/2011 Description Draft for internal review Candidate draft Originator A. Chave A. Chave Approval Signature This Integration and Verification Plan has been reviewed and approved for use. Approval Authority Name (print): Tim Ampe Approval Authority Title: System Development Manager Approval Authority Signature: Approval Date: Approval Authority Name (print): Alan Chave Approval Authority Title: Senior System Engineer Approval Authority Signature: Approval Date: Approval Authority Name (print): Jack Kleinert Approval Authority Title: QA Manager Approval Authority Signature: Approval Date: Approval Authority Name (print): Matthew Arrott Approval Authority Title: Project Manager Approval Authority Signature: Approval Date: Ver 1-00 1160-00000 i .

....... 5 Appendices...............................................2...................................5 Witness(es)..................................................2 Item(s) to be Integrated and Verified.................................................1..........3 5.......................... 4 9 Safety Considerations..2 Integration and Verification Personnel...... 2 4 Integration and Verification Methodology.......................2...........................2.............................................................................................................................. 4 7 Integration and Verification Schedule.............................2 3................................4 Cross-IO Participants......................1 Integration and Verification Leads..............................1 Purpose of Integration and Verification........................... 4 6 Data Collection and Analysis Plan......... 3 5.... 5 11........2.......................................... 4 5... 2 3 Integration and Verification Environment..........2......... 3 5..................................... 4 7................. 2 2................................ 3 5.....2 Integration and Verification Conductor...................................................................................................................3 5....................3 Specialized Computer Hardware................................1 Integration and Verification Location..1 Integration and Verification Materials and Equipment.......................... 4 5.........................................................................................................................................................1 General References.........3 Integration and Verification Objectives................................................................................................ 4 8 Test Costs............................................................................. 4 7..............................................................................................................2 Environmental Constraints....................2 3..........................6 QA/QC........................................................1..................3 5............................2 5 Integration and Verification Resources......1 Prerequisite Events..........................3 Input Data....2 Specialized Equipment.........................3 Expected Duration.........................................1.......................................................................................................................................................1 2 Reference Documents..................... 4 5.............................................................................................................1 Specialized Materials........................................................................................ 3 5...... 1 1....................................3 Other Participants..2.......................................................................................................................................2 Planned Start Date............................................................2........................ 4 7............................................. 14 Ver 1-00 1160-00000 ii ........5 11 Requirements to be Verified......................4 Software.........................................................................1........................................................................................................................................................................................................1 1.................................................................................. 2 2................................................................................................................................................................................................................Integration and Verification Plan Table of Contents: 1 Integration and Verification Overview....................................................................................................................................................... 5 10 Environmental and Permitting Considerations...................................................... 4 5........................................................................................2 Specific Test References...........................................................................................................................7 Approval Authorities............................................................................3 5..............................1 1......................................................................................................................................... 3 5.......................1 Table of Requirements.........................................................................................................................................3 5.........

For the CI. For R1. with the former combined with unit testing. Integration refers to the incremental aggregation of service components into service groups. or in other words asks the question “was the right system built?”. with the specifics about what is integrated. and will be carried out using the OOI acceptance procedures during the Transition phase of the CI system life cycle Ver 1-08 1160-00000 1 . Verification refers to testing against the L4 requirements for the subsystems that occurs during the Transition phase of the CI system life cycle. and hence not addressed in this plan. the following five subsystems are under construction. 1. Validation is a separate activity that confirms that the system meets user needs as built. validation focuses on the user workflows defined in 2130-00005 R1 Functional Design Specification and 213000006 R1 Functional Detail Specification. Black box integration at the subsystem and system levels is covered by this plan. and that the outcome is functional software. For R1. as the L3 requirements are verified as rollups of the L4s. service groups and subsystems with increasing definition until a complete system is available. except that the Instrument and Platform Agent requirements are in the L4 Marine CyberPoPNetwork module. the L4 requirements are the focus of verification.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 due to complete in July 2011. how it is integrated and when it is integrated contained in 2160-00001 R1 Integration Plan. or in other words asks the question “was the system built right?”. and will be integrated and verified: Common Operating Infrastructure Common Execution Infrastructure Data Management Sensing 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. 1. and subsystems into an integrated system that occurs during the Construction phase of the CI system life cycle. The objective of integration is ensuring that all internal and external interfaces are implemented correctly. Verification is testing the integrated software to ensure its compliance with requirements. The specific software elements that will be integrated and verified are captured in 216000002 R1 Integration Procedures and 2160-00003 R1 Verification Procedures documents. This is divided into white box and black box integration.Integration and Verification Plan 1 Integration and Verification Overview 1. service groups into subsystems.3 Integration and Verification Objectives Integration is the incremental aggregation of service components. The IVP establishes the plans for CI I&V activities that precede acceptance.2 Item(s) to be Integrated and Verified During R1. verification occurs at the level of subsystems or groups of subsystems once the integrated system is complete even if a given requirement is implemented at the service component or service group level.

Amazon EC2). For R1.Integration and Verification Plan 2 2. and focus on data formats. Test – the quantitative exhibition of functional performance with known inputs and an expected output that is usually not feasible when many interacting software elements are involved. for example. the following three verification methods will be utilized: Inspection . the only interface requirements to be verified occur in the External Observatory Integration module. This methodology is documented in the Integration Procedure document. of R1 follows the standard approach of a bottom up approach.examination of a software item against applicable documentation to confirm compliance with requirements.2 Specific Test References 1150-0100x R1 Acceptance Procedures 2160-00001 R1 Integration Procedures 2160-00002 R1 Verification Procedures 3 3. Demonstration (a set of test activities with system inputs and conditions selected by the system developer) may be used to show that the dynamical response of a subsystem or system is appropriate. the requirement that a service component be extensible is evaluated by direct code and code documentation examination. University of California at San Diego using both the UCSD development and test environment and external provider resources located in the cloud (e. For R1. Demonstration – the qualitative exhibition of functional or behavioral performance.g. 3.2 Environmental Constraints None 4 Integration and Verification Methodology Integration. and specifically black box integration at the subsystem level and higher.. Each requirement to be verified in R1 has been assigned to one of these three classes using Ver 1-08 1160-00000 2 . in which an increasingly complex series of builds are integrated and tested. Test and Verification Strategy version 2-21 2.1 Reference Documents General References 1100-00000 OOI System Engineering Management Plan version 3-14 1150-00000 OOI Test and Evaluation Strategy version 0-06 2010-00002 CI Quality Assurance/Quality Control Plan version 2-00 2110-000005 CI Integration. Integration is carried out during Construction.1 Integration and Verification Environment Integration and Verification Location All I&V activities will be carried out at Atkinson Hall.

com/ccc? key=0AvOM5_fPfsmudGZmSXBoM2FwZzhzTzNra1JUcXJJRGc&hl=en&authkey=C M6MjOUI#gid=0 5. Additional equipment for integration and verification is limited to one or more laptop computers with a standard web browser. some Common Execution Infrastructure verification activities require the use of additional resources located in the cloud.1. verification of some of the Marine CyberPoPNetwork requirements must include an exemplar instrument that.org/display/CIDev/System+Development+Envi ronment.4 Specialized Computer Hardware See 5. 5. In addition.3 Other Participants CI Management Team and Senior Developers as required Ver 1-08 1160-00000 3 . This includes the programming environment.2 Integration and Verification Personnel 5. 5 5.3 5.google.Integration and Verification Plan the Verification Method attribute in DOORS. UCSD) Tim Ampe (System Development Manager.2 Specialized Materials None Specialized Equipment Integration is carried out using the UCSD software development and test environment documented at https://confluence. documentation procedures.1.2 Integration and Verification Conductor Jamie Chen (Integration and Test Lead. UCSD) Alan Chave (Senior System Engineer. UCSD) 5.2.1 Integration and Verification Leads Jamie Chen (Integration and Test Lead. and are typically implemented using a commercial provider such as Amazon EC2. WHOI) 5. source code and version control.1 Integration and Verification Resources Integration and Verification Materials and Equipment 5.1 5.2. the I&T Team.1.1.2. Verification procedures were then written by the Senior System Engineer. and the Senior Developers.oceanobservatories. unit testing including automated testing and reports. Finally. Software The R1 software and its dependencies are documented at https://spreadsheets. Verification is carried out using the same hardware environment. UCSD) Roger Unwin (Integration and Test Developer.2. will be a Seabird CTD immersed in a bucket of water. and the development environment. These will be executed during Transition.1. for R1.

2.com/ooici-eoi/eoiagents/blob/develop/src/net/ooici/eoi/datasetagent/impl/UsgsAgent. is a prerequisite gateway that both validates the successful completion of an integrated and tested release and serves as a Test Readiness Review for the verification procedures. Ver 1-08 1160-00000 4 . 8 Test Costs Costs of integration and verification are consistent with those allocated to WBS number <number>. 7 7. 7. UCSD) 5.1 Integration and Verification Schedule Prerequisite Events Successful completion of the Initial Operating Capability milestone review scheduled for May 25. For R1. Verification begins with the start of the Transition phase on May 30. there is no expectation to ingest.2. 2011. 2011.gov/.7 Cross-IO Participants N/A Witness(es) Kathy Carr (OOI Requirements and Test Lead) at the discretion of the PMO QA/QC Jack Kleinert (QA Manager. SiteCode: 0118400) available from http://waterservices.2 Planned Start Date Integration is an ongoing activity during the third iteration of Construction that spans February 14 through May 13. Raytheon IIS) Approval Authorities Matthew Arrott (Project Manager. They have been converted from WaterML1. persist or reproduce any extensive amounts of data. CT (network: NWIS.usgs. AgencyCode: USGS.2.Integration and Verification Plan 5.java 6 Data Collection and Analysis Plan The Verification Procedures list the expected output for all tests and demonstrations. The move from Construction to Transition cannot occur without completion of this milestone. 7.6 5.2.4 5.3 Expected Duration The Transition phase spans 8 weeks.5 5. 2011.3 Input Data Verification of requirements that require the input of a data set will utilize the USGS rivers data time series Connecticut River at Thompsonville.1 to the OOI Common Data Model for internal CI use by code at https://github.

The presentation framework shall support HTML4-compliant browsers The presentation framework shall provide the web user interface “portlet” building blocks The presentation framework shall be extensible The governance framework shall implement a policy-based decision system for resource access The governance framework shall provide policy enforcement services The governance framework shall provide policy decision services The governance framework shall enforce authorization of resource access for actors The governance framework shall provide different levels of access for actors or resources with Rationale & Description Publish/subscribe mode is the standard method of communication in the OOI Pull mode communication requires storage of messages until they are requested Streaming means asynchronous. T Test Proc COI-2 T COI-3 L4-CI-COIRQ-50 T COI-4 T COI-5 L4-CI-COIRQ-53 L4-CI-COIRQ-278 L4-CI-COIRQ-55 L4-CI-COIRQ-279 L4-CI-COIRQ-58 L4-CI-COIRQ-280 L4-CI-COIRQ-281 L4-CI-COIRQ-59 L4-CI-COIRQ-61 D D I The core capability to manage resource access T COI-6 COI-7 COI-1 COI-8 T T For actor to resource interactions For example.Integration and Verification Plan 9 Safety Considerations None 10 Environmental and Permitting Considerations None 11 Requirements to be Verified 11. The messaging framework shall provide store until requested communication The messaging framework shall provide streaming communication The messaging framework shall provide peer-to-peer communication between distributed resources.1 Table of Requirements RQ Number L4-CI-COIRQ-46 L4-CI-COIRQ-49 RQ Text The messaging framework shall provide topic-based communication. continuous transmission This includes resources on the seafloor Verif. Meth. access to instrument management requires an additional T T COI-8 COI-8 COI-8 COI-8 Ver 1-08 1160-00000 5 .

institution. T COI-12 L4-CI-COIRQ-85 L4-CI-COIRQ-88 L4-CI-COIRQ-89 L4-CI-COIRQ-330 L4-CI-COIRQ-331 L4-CI-COIRQ-332 L4-CI-COI- The identity management services shall associate any OOI-recognized entity with a persistent OOI identity. nonreassignable identifier for the user. Trusted identity providers could be commercial entities like Verisign or OOI member institutions. phone and email address T COI-12 T COI-12 Access is restricted to specified parties D D T T COI-13 COI-14 COI-12 COI-12 Ver 1-08 1160-00000 6 .Integration and Verification Plan different levels of authorization. L4-CI-COIRQ-285 L4-CI-COIRQ-289 L4-CI-COIRQ-290 L4-CI-COIRQ-291 L4-CI-COIRQ-292 L4-CI-COIRQ-342 L4-CI-COIRQ-74 L4-CI-COIRQ-77 L4-CI-COIRQ-80 The services framework shall enforce policy The distributed state services shall provide an attribute store The distributed state services shall be concurrent The distributed state services shall support multiple services The distributed state services shall provide consistent state information across the OOI network The distributed state services shall manage state divergence via branching The identity management services shall support authentication of all actors accessing the OOI network The identity management services shall recognize identity credentials issued by external trusted issuers The identity management services shall accept authentication tokens from trusted identity providers authorization from access to its data stream T T T T T COI-8 COI-9 COI-10 COI-10 COI-11 T T COI-11 COI-12 T COI-12 The authentication token contains a persistent. The identity management services shall require validated contact information for all actors accessing OOI resources The identity management services shall map the identity asserted by an identity provider in an authentication token to an OOI user identity A user interface to register actor identities with the OOI shall be provided A user interface to authenticate actors shall be provided An identity registry to store the identities of actors shall be provided The identity registry shall T COI-12 A minimum set of criteria might include name.

D COI-16 CEI-1 L4-CI-CEIRQ-31 L4-CI-CEIRQ-32 L4-CI-CEIRQ-33 L4-CI-CEIRQ-34 L4-CI-CEIRQ-37 L4-CI-CEIRQ-46 L4-CI-CEIRQ-47 L4-CI-CEIRQ-50 L4-CI-CEIRQ-85 L4-CI-CEIRQ-86 L4-CI-CEIRQ-105 The elastic computing services shall schedule virtual machines based on available execution resources The elastic computing services shall monitor executing processes The elastic computing services shall publish information about executing virtual machine instances The elastic computing services shall dynamically add and remove execution resources to meet demand subject to policy The elastic computing services shall utilize execution resources subject to policy The resource management services shall monitor stateful resources under CI governance The resource management services shall control taskable resources under CI governance The resource management service shall publish resource attributes obtained by monitoring stateful resources The resource management services shall provision execution resources according to policy The resource management service shall manage execution resources according to policy The resource management services shall manage service D CEI-2 D D CEI-3 CEI-4 D CEI-5 D D D D CEI-6 CEI-7 CEI-8 CEI-7 D CEI-8 D D CEI-8 CEI-9 Ver 1-08 1160-00000 7 . A virtualization layer ensures that available storage and computational resources are made available to such processes.Integration and Verification Plan RQ-333 L4-CI-COIRQ-118 L4-CI-COIRQ-119 L4-CI-CEIRQ-30 maintain the association of internal identities with external identities The resource catalog services shall manage information about all resources under CI governance The resource catalog services shall manage resource metadata The elastic computing services shall execute virtual machines independent of the execution environment T COI-15 T This means that the process definitions are independent of the physical execution environment in which they operate.

and might include location for a physical resource or the model and parameters for a data product The model must accommodate new descriptive information as needed Providing geospatial and temporal coordinates is a fundamental feature for data access and operations.Integration and Verification Plan L4-CI-CEIRQ-106 L4-CI-DMRQ-32 process definitions The resource management services shall manage the instantiation of service processes The OOI-standard metadata model shall include a syntactic description for the content of an information resource The OOI-standard metadata model shall include tracking of context D CEI-9 Syntax refers to the structure.html#File-Format The evolving CF Metadata Conventions provide community agreements for representing coordinate systems and comparing physical quantities. such as a definition of the fields in a multi-column data set Context is information about resource usage. See http://www. CFcompliance may be applied to other syntactic formats.ucar. preserved in I DM-1 L4-CI-DMRQ-36 I DM-1 L4-CI-DMRQ-40 L4-CI-DMRQ-143 The OOI-standard metadata model shall be extensible. Although limited in scope to certain data models defined in terms of netCDF.e du/software/netcdf/docs/n etcdf/FileFormat. Vertical (3D) coordinate conventions are not yet widely supported in the GIS community but are critical to the Ocean science community This format is so prevalent in the community that it rises to the level of a requirement. Internal data models shall be capable of including coordinate data in scientific feature types I DM-1 I DM-1 L4-CI-DMRQ-49 L4-CI-DMRQ-149 The internal data models shall be extensible The set of supported external data file formats shall include NetCDF Classic (3) I I DM-1 DM-2 L4-CI-DMRQ-145 Data shall be exportable using the CF Conventions T DM-5 Ver 1-08 1160-00000 8 .unidata.

it should be standard enough to import into the internal own data model. See http://opendap.gov/ If the external data set follows the CF conventions. L4-CI-DMRQ-146 Data shall be ingestible using the CF Conventions to build an internal data model T DM-6 L4-CI-DMRQ-148 L4-CI-DMRQ-151 The set of external data file formats that can be generated from an internal data model shall be extensible The list of external data interfaces through which data can be ingested into an internal data model shall be extensible The list of external data interfaces through which data can be exported from an internal data model shall be extensible The list of external data interfaces shall include the OPeNDAP Data Access Protocol V2 I DM-3 New and evolving data access protocol standards in the community will require the OOI-CI to evolve as well I DM-3 L4-CI-DMRQ-152 I DM-3 L4-CI-DMRQ-153 L4-CI-DMRQ-51 L4-CI-DMRQ-52 L4-CI-DMRQ-181 The dynamic data distribution services shall publish data from distributed data sources The dynamic data distribution services shall allow users to subscribe to data topics The dynamic data distribution services shall implement the definition of This protocol is so prevalent in the community that it rises to the level of a requirement.html This includes both physical resources and data repositories This carries with it the requirement for a registration service This includes the implementation of a topic from metadata T DM-5 D DM-7 D DM-7 D DM-7 Ver 1-08 1160-00000 9 .llnl.Integration and Verification Plan OPeNDAP access. See http://cf-pcmdi. Additions to CF can be proposed through a welldefined open community process. Not all data sets can necessarily be made to fit into this model.org/faq/w hatIsDods. The CI should keep up with the latest developments in the OPenDAP community while still providing backward compatible protocols for older client applications. and checked automatically.

aggregates or data messages from multiple data sources. any form of derived data messages. continuing with new data as they are generated This carries with it the requirement for a notification service and interface D DM-8 L4-CI-DMRQ-180 The dynamic data distribution services shall associate data streams with data resources D DM-8 L4-CI-DMRQ-54 The dynamic data distribution services shall provide notification about data topic change A graphical user interface to register for data topic subscription shall be provided A graphical user interface to register for data topic notification shall be provided The data catalog services shall allow federation The data catalog service shall cross-reference OOI and external repositories The data catalog services shall cross-reference the data catalog with the observatory resource catalog The data catalog services shall permanently associate metadata with all cataloged data The data catalog services shall be capable of adding metadata attributes A unique identifier mechanism for identifying data sets shall be provided A unique identifier mechanism for identifying parts of data sets shall be D DM-7 L4-CI-DMRQ-130 L4-CI-DMRQ-131 L4-CI-DMRQ-61 L4-CI-DMRQ-64 L4-CI-DMRQ-136 D DM-9 D DM-9 Cataloging must not depend on the location of data D D DM-10 DM-10 DM-10 There should be one stop shopping for observatory resources. if a real time data stream has a historic record. D L4-CI-DMRQ-132 L4-CI-DMRQ-158 L4-CI-DMRQ-159 L4-CI-DMRQ-160 T DM-11 T Needs to include data set identifier and version control I I DM-12 DM-4 DM-4 Ver 1-08 1160-00000 10 . For example. subsets. distinguishable by message attributes. a subscriber can reply the stream with a start time in the past.Integration and Verification Plan L4-CI-DMRQ-182 data topics The dynamic data distribution services shall support multiple data messages on a given data stream A data stream may carry data messages from one data source only.

For example. and integrating them into a single D DM-20 Ver 1-08 1160-00000 11 .Integration and Verification Plan L4-CI-DMRQ-161 L4-CI-DMRQ-70 L4-CI-DMRQ-162 L4-CI-DMRQ-183 provided The unique identifier mechanism for data sets shall include version identification capability The data discovery services shall be capable of contentbased recognition A graphical user interface for data discovery shall be provided The data ingestion services shall manage ingestion of a data set I DM-4 This entails the requirement to find data through keywords in them D DM-10 D Service to make science data known to the DM system for subsequent storage in a repository with metadata attached and cross-referenced T DM-10 DM-13 L4-CI-DMRQ-186 L4-CI-DMRQ-184 L4-CI-DMRQ-188 L4-CI-DMRQ-189 L4-CI-DMRQ-73 The data ingestion services shall be capable of linking to topics The data ingestion services shall be indifferent to delivery order The data ingestion services shall manage data stream metadata A user interface for the ingestion services shall be provided The metadata management services shall utilize the defined vocabularies The persistent archive services shall be data format agnostic The persistent archive services shall preserve all associations between data and metadata The persistent archive services shall ingest and integrate data sets that arrive out of order or in overlapping parts T T T D This facilitates the transformation of proprietary metadata formats into the OOI standard T DM-14 DM-15 DM-16 DM-17 DM-6 L4-CI-DMRQ-77 L4-CI-DMRQ-79 L4-CI-DMRQ-80 D T DM-18 DM-19 Data may arrive in different quantities at different times. mooring data may be delivered in a decimated form in near real time. with the entire data set appearing at annual service times. The archive services must be capable of connecting the decimated and complete data sets.

according to a time schedule. and/or vice versa Register as a data source. This presumes that the external observatory already has an internal identity. For example. Push mode means that the originating observatory or OOI dictate when data are transferred. I DM-21 DM-22 EOI-1 L4-CI-EOIRQ-43 The Dataset Agent shall register a dataset from an external observatory with the CI The Dataset Agent shall acquire data from an external observatory The Dataset Agent shall implement poll mode data transfer The Dataset Agent shall implement push mode data transfer D EOI-3 L4-CI-EOIRQ-23 L4-CI-EOIRQ-24 L4-CI-EOIRQ-25 D EOI-3 D EOI-3 D EOI-3 L4-CI-EOIRQ-26 L4-CI-EOIRQ-27 L4-CI-EOIRQ-28 L4-CI-EOIRQ-29 L4-CI-EOIRQ-30 L4-CI-EOI- The Dataset Agent shall acquire associated metadata for all data transferred from an external observatory The Dataset Agent shall transform the external observatory data model to the OOI Common Data Model The Dataset Agent shall transform the external observatory metadata model to the OOI Common Metadata Model The Dataset Agent shall publish data to the Exchange The Dataset Agent shall publish invariant metadata to the Exchange The Dataset Agent shall D EOI-3 D EOI-3 D EOI-3 D D D EOI-3 EOI-4 EOI-5 Ver 1-08 1160-00000 12 .Integration and Verification Plan archived data set L4-CI-DMRQ-82 L4-CI-DMRQ-84 L4-CI-EOIRQ-22 The persistent archive services shall support distributed data repositories The persistent archive services shall support data versioning Each Dataset Agent shall be the logical representation of a specified external observatory D T Dataset Agents must be customized to the interface and capabilities of a given external observatory and represent it to the CI. Using the data model appropriate to a given external observatory Polling means that the DA dictates when data are transferred.

Int EOI-8 D D SA-6 SA-6 Instrument Agents must be customized to the interface of a given sensor or actuator type and represent it uniformly to the CI. presuming the instrument maintains T SA-2 SA-2 L4-CI-IMPRQ-391 The Instrument Agent shall acquire metadata from a physical instrument T SA-3 Ver 1-08 1160-00000 13 . New and evolving data standards in the community will require the OOI-CI to evolve as well D I EOI-6 EOI-3 EOI-2 L4-CI-EOIRQ-41 L4-CI-EOIRQ-42 L4-CI-SARQ-222 L4-CI-SARQ-140 L4-CI-IMPRQ-35 The IOOS Dataset Agent shall process data that conform with the Unidata Common Data Model The IOOS Dataset Agent shall process data that conform to a described ASCII text model Control services for physical resources shall be provided A user interface to the control services for physical resource control shall be provided Each Instrument Agent shall be the logical representation of a specified physical instrument type The Instrument Agent shall acquire data from a physical or simulated instrument The Instrument Agent shall implement push mode data acquisition D.Integration and Verification Plan RQ-31 L4-CI-EOIRQ-32 L4-CI-EOIRQ-33 L4-CI-EOIRQ-36 L4-CI-EOIRQ-46 publish variant metadata to the Exchange when change occurs The Dataset Agent shall acquire external observatory status information The Dataset Agent shall publish external observatory status to the Exchange The Dataset Agent shall acquire commands from the Exchange The set of external data file formats that can be ingested into an internal data model shall be extensible Op/Nonop at a minimum. but additional information about internal status if it is available D EOI-6 D Commands from the CI to the DA This addresses the bits and bytes on disk and how they are arranged (NetCDF. I SA-1 L4-CI-IMPRQ-36 L4-CI-IMPRQ-53 T Push mode is used for sensors/actuators that can be scheduled to collect data autonomously so that the IA acquires them passively This includes variant and invariant metadata. Int EOI-7 D. HDF. GRIB etc).

refer to these documents in Section 2).Integration and Verification Plan these internally L4-CI-IMPRQ-51 L4-CI-IMPRQ-50 L4-CI-IMPRQ-254 L4-CI-IMPRQ-38 L4-CI-IMPRQ-41 The Instrument Agent shall translate instrument-specific data to OOI-specific formats The Instrument Agent shall publish data to the Exchange The Instrument Agent shall publish instrument metadata to the Exchange The Instrument Agent shall publish variant metadata when change occurs The Instrument Agent shall handle instrument events T T T T This covers events detected by the instrument. T SA-2 SA-2 SA-4 SA-4 SA-2 SA-5 L4-CI-IMPRQ-43 L4-CI-IMPRQ-37 The Instrument Agent shall manage instrument state The Instrument Agent shall acquire commands from the Exchange T T SA-4 SA-5 L4-CI-IMPRQ-39 L4-CI-IMPRQ-42 The Instrument Agent shall issue commands to a physical instrument The Instrument Agent shall translate CI commands to instrument-specific commands The Instrument Agent shall timestamp data as they are acquired T This could be commands from the Platform Agent or from some part of the CI. as opposed to those detected by the IA This could be commands from the Platform Agent to the IA or some other part of the CI directly to the IA.> Ver 1-08 1160-00000 14 . depending on the deployment specifics. T SA-5 SA-5 L4-CI-IMPRQ-587 T SA-2 Appendices <Attach relevant diagrams and documents that are not controlled separately (If controlled separately. depending on the deployment specifics.