Building a U.S. Integrated Ocean Observing System

Krish NarasimhanLockheed MartinMS 861/4D34

9231, Corporate BlvdRockville, MD 20850.

Abstract - This paper outlines the need, the environment, and issues surrounding the development of a national U.S. IntegratedOcean Observing System (IOOS). It also provides an overview of a solution to the U.S. IOOS based on a Service-Oriented Architecturethat is consistent with the vision of an IOOS as articulated in the publications from Ocean.US.

This paper is slanted technically. It is recognized however that building IOOS has significant dependencies on non-technical mattersamongst which funding and governance structure are critical.

I. INTRODUCTION

The U.S. Integrated Ocean Observing System (IOOS) is envisioned to bring together the variety of ocean observing systems inplace today into a cohesive system-of-systems that enables all stakeholders to significantly enhance their current abilities toanalyze and understand the multitude of ocean-triggered and ocean-related phenomena that affects life on earth, and to betterpredict changes, and very importantly, to manage and sustain ocean and coastal resources.

Operationally, IOOS is envisioned to be a coordinated national and international network of Observing and Modeling/Analysissystems that systematically and efficiently acquires and disseminates information on past, present and future states of the oceansand coastal waters.

A significant amount ofwork has been done to date in developing this vision of IOOS by Government, Academia and theIndustry ([1], [2], [3], [4]). Past work has also captured the societal and business needs driving IOOS as well as many conceptspertaining to its realization.

IOOS has been viewed as being made up of three major sub-systems - 1) Observing Sub-system (OS), 2) Data Management andCommunication Sub-system (DMAC), and 3) Modeling and Analysis Sub-system (M&A), with the DMAC sub-system providingthe interconnectivity between the OS and M&A sub-systems.

It is perhaps appropriate and important to add a fourth 'sub-system' namely, the Product and Services 'sub-system' that representsthe usable end products and services generated from the activities of the other three sub-systems.

0-933957-35-1 ©2007 MTS

Figure 1 below illustrates a high-level view of IOOS with thefour sub-systems.

Figure 1: Integrated Ocean Observing System (IOOS)

The significance of explicitly including the Products and Services 'sub-system' is to underscore the importance of building anIOOS that is user-focused and that ultimately supports not only marine/ocean research but also the operational needs of the greatvariety ofIOOS stakeholders - from Government agencies and authorities at Federal, State and local levels, to academia, to non-governmental organizations, to industry, and last but not least, to the general public. End-user products and services almostalways are tied very closely to decision support, and can be viewed to be the outputs of 'applications' that use IOOS data.

It is also important to note that the IOOS is envisioned to interface to a global earth observing system-of-systems (GEOSS) thusrequiring IOOS to support powerful and efficient interfaces to external entities.

Building IOOS is a comprehensive task that should address the technical, operational and very importantly the governanceaspects, given the large number and variety of stakeholders expected to be engaged. Several constraints and factors should betaken into consideration in developing and building IOOS, key amongst which are the following:

1) IOOS is about integrating existing assets engaged in observing and modeling and analysis, and not about creating abrand new system from scratch.

2) IOOS must support the continuous evolution of observing and modeling and analysis assets as well as the expeditiousintroduction ofnew assets

3) IOOS must not require a tight implementation and operational inter-dependency amongst its stakeholders (in otherwords, it must support afederated operational environment)

4) IOOS must be economically viable both for its initial implementation and for its on-going operations5) IOOS must be sustainable over the long-haul6) IOOS must support a minimal set of products and services at its initial operational capability point

Before describing an approach to building IOOS, it is important to capture concepts of IOOS operations, as described in thefollowing paragraphs.

The challenge ofIOOS can be viewed to consist of a marine/ocean science part and an information management part. Themarine/ocean science part can be viewed to be the focus of the Observing and Modeling/Analysis sub-system while theinformation management part can be viewed to be the focus of the Data Management and Communications sub-system.

0-933957-35-1 ©2007 MTS

The IOOS Observing sub-system does and will continue to consist of a wide variety of systems and elements whose basic role isto measure fundamental ocean parameters and variables. The IOOS Development Plan calls for a list of core variables that formthe basis of coastal data and information that should be made available through IOOS.

The IOOS Modeling and Analysis sub-system plays an important role in driving the ultimate success of IOOS, for it is theprimary 'gateway' for the products and services that come out of IOOS. The Modeling and Analysis environment will consist of acollection of tools that will link the output of the Observing sub-system to the desired set of products and services. These toolswill span from simple 'rules of thumb' to sophisticated algorithms and numerical models that take the raw observed data andtransform them either directly into end-user products and services or provide intermediate products that are processed further bystakeholders toward a specific product or service.

The IOOS Data Management and Communication sub-system is pivotal to the formation of IOOS. Without an effective DMACsub-system, effective and comprehensive utilization of data emanating from existing and new Observing and Modeling andAnalysis assets will remain unrealized, which in turn will severely limit the spectrum of usable and useful products and servicesthat can be made available to the stakeholders.

The task of building IOOS therefore must initially focus on defining, designing and implementing the DMAC sub-system. TheDMAC sub-system, once in place, will enable the systematic and incremental integration of existing and new observing andmodeling and analysis assets.

Another perspective on DMAC can be obtained by viewing IOOS as an environment consisting of data providers and dataconsumers. Here the term 'data' is used very broadly, and includes core variables, pre-processed observations, algorithms,numerical models, and even end products and services. From this perspective, DMAC can be viewed as a trusted facilitator of theexchange of data/information between providers and consumers.

The primary objective of the DMAC sub-system is IOOS information management. Information management should not beviewed only as the information technology part consisting of hardware and software with supporting facilities and staff that willunder-pin DMAC. The primary objective of the DMAC sub-system should be to define a data framework that enables theassimilation, dissemination, and management of the wide spectrum of marine/ocean data- from relatively simple structured, high-volume physical ocean parameters to complex structured, low-volume biological parameters - much of which is geo-spatial. Thistechnical standardization part should be complemented by the definition of an operational governance framework without whichthe vision of IOOS as a system-of-systems will be unrealized.

Technical standards should be a collection of specifications that define the rules by which an IOOS asset makes its data (andfunctionality) understandable and accessible in IOOS. 'Understandable' means that receiving entities of the asset's data canreadily process the data after obtaining it, without significant further intervention on the part of the providing asset. This willrequire standardization of taxonomies, data dictionaries, and metadata. 'Accessible' means that the receiving entity knows exactlywhat interface mechanisms and policies are implemented at the provider asset's end in order for it to obtain the data.

The operational governance should be a collection of policies that define the rules by which stewards of IOOS assets formulatetheir engagement in IOOS in a consistent manner with regard to factors such as what data is made available, how that data isaccessible, the quality of data, data access control, and data security.

The technical standards and the operational governance essentially form the 'glue' that holds the DMAC sub-system together, andby extension they hold the entire IOOS together.

The DMAC sub-system should also include other functional components that add value to IOOS stakeholders such as ease ofdiscovery of data (e.g., an IOOS-tailored Google), long term archival of IOOS data, transformation of data from legacy observingsystems to IOOS standards, etc.

Building IOOS

Based on the concepts outlined above, a viable approach to building IOOS is the adoption of a Service Oriented Architecture witha staged implementation plan under-pinned by a comprehensive System Engineering process.

Much literature is available in the open market discussing the merits of Service Oriented Architecture in support of a system-of-systems in a federated environment [5]. SOA as a concept is not brand new. The underlying elements of SOA - in particular the

0-933957-35-1 ©2007 MTS

mechanism of data communication amongst heterogeneous systems using standards-based messages and protocols have beenimplemented successfully in the past. SOA is the latest step in that evolutionary process, and benefits greatly from equallyimportant technology developments such as the Internet, Web Services, and Distributed Computing which significantly enable its'Publish and Subscribe' model. Web Services and the Internet are expected to play a prominent role in the realization of IOOS.

Two characteristics of SOA that particularly suit its application to IOOS are:

* Tightly coupled technical governance that singularly enables interoperability* Loosely coupled operational governance that enables diverse business operational models and incremental implementation

The outcome of the Service Oriented Architecture in IOOS is that in the end state, each contributing asset - be it an observingasset or a modeling and analysis asset or an end product or service providing asset - essentially becomes a service node within theIOOS network, exposing its data and functionality in the form of standards-based services. Examples of a contributing assetinclude Sensor platforms, Data Assembly Centers, Satellite ground stations, Domain-specific data centers such as the NationalMarine Fisheries Science Centers, the National Data Buoy Center, University research centers, or gateway points within programssuch as NSF Orion, or EPA's Exchange Network.

The loosely coupled operational governance aspect of SOA also facilitates the independent development of IOOS at regional andlocal levels (e.g., at a Regional Association level) that can eventually be integrated into the U.S. IOOS, as long as the regional andlocal level implementations conform to the stipulations of the technical governance aspects of the SOA.

Figure 2 below illustrates the end-state concept of IOOS based on SOA.

Erd U sersZ

at Asmly .;_i:.

Cete

..........................

..........

..........

__EData AsemblyCenlter

E,Us=es,..rs 0I II avr SS;

*nter

lEnd Users!

Figure 2: IOOS - Network of Service Nodes

Central to the service node concept is the implementation of an integration layer within that asset that makes its data (orfunctionality) available in IOOS standards in the following two critical areas:

* Metadata* Interface Mechanism

It is recognized that ocean/marine data are made available in a great variety of structures and formats, and will continue to beavailable in that manner, especially given the diverse and expanding categories of ocean parameters, models, products andservices that come into play. It therefore would not be appropriate for IOOS to specify a single format or even a narrow set of'acceptable' formats. Instead, IOOS shouldfocus on defining standardsfor the Metadata and Interface Mechanism that support

0-933957-35-1 ©2007 MTS

Edd UW§ 00

4

I

the accurate discovery and efficient transport of those data structures and formats thereby enabling their accessibility andprocessing.

Figure 3 below illustrates the ISO/OSI stack view of an asset's integration layers

l~~~~~~~~~Aa§CCD M~ Fllocus oflOQOSw r ~~~~~~~~~~~~~~~~~~~~~~Standardization*~~~FGDCCSDGMs

*~~ OGC

It s citial hatJOO goernnceratfy igcoereto stnarsI OS negacr e f tnadsratified impemntngth

in tegation layler, withnandasdspertaisinaorltivel strAigtowrsbytengneigpoesmsnappropritothmpemnateoo tehOlOgiesIatwr is ImOrtantnthabythJOOS goeranc minimizeestipuldatingsstandardsthataforc theueofpearatiuaranytehnlointraes.Forvexample thoitughreWhebr

elemelntsta dorntafceneoerblt iety

*t2eISOp1e1entation

A large-saledfderated sytem-of-sysesuch as JOOS shouldbeML iAMpLemne) nrmnal,satigwt nerytse

Itinvlvncical thanduIOfS systemsncfromifafe commtedsto stakeoderds.tvnerf thcore coftnceptss ouatlined abovemincluing theineratifie stnayrds,ina sstiantovrf theluabivlyandaiperformancdotengoverall arochiectureThisg willopguardaehnlgainstprpgtingmprtnarhitectura elemerntsc thatifall shotiofumeting perfoarmstancerhequirmnse sucpastiu'rteahnl-timecess,Fo aequatpe,transportb

Onrvcestheearnloytestbenvriiciatiodi ompletedaplamnentoed inhmplementation ofJOOS,twrsitsandriztia Opertional Capdability

prioritizedelsetnof obsWervn andicemoelinolgyand analsis aocsseloleetsthatsolbeitgaed.narefle considoerationt must beagventouthcosmetsasocatedowith dfeveloingtheroeainitegdractinlayerfrteast.novd eualotaemdlsiatclrwl

enabledaImlmoeraiandt ibeitgation poessuigtesceso C

Th majrgesae fdeplomete tsksemof-sseJuhaOOSisteenacmetfomlJOet itsFulemOperatincrmnalCpbliy, (FOC),nwihereearll identifiedassetsinbeom partfu of sythemnewrkof servc nodes.tIt istarecognized tha JOOSf willboeconacpsontinuosevaolutioncespeiallone

pirthe d etoobserving and modelingdmis andtatnewsiassetswill shulbe integrated.intoateonuaon-gigbsis.ainmutb ivnt h

costs associated ith developing the integration layer for the................................................. assets...............involved...........R e-usable... s.o.................................................i..u................enable ore rapid and viable integration process, assuring the success of IO C.........................................................................................................................................................

The ajor deploym ent task of IOOS is the enhancem ent from IOC to its Full Operational Capability (FOC), where all identified..................................................................................................................................

a..................... evolution............................... -......... especially.............................. on.....................................

0-933957-35-1 ©2007 MTS

Another advantage of a staged implementation is the more efficient utilization of the funding stream.

System Engineering

IOOS will benefit greatly in adopting an industry best practice System Engineering approach to its implementation. SystemEngineering as a discipline is well established, documented and practiced. In the context of IOOS, System Engineering will mean:

* Prioritizing and defining a set of products and services needed at IOC* Detailed inventorying of existing observation and modeling systems that are expected to play a prominent role at IOC* Assessing the capabilities of the existing observation and modeling systems vis-a-vis the prioritized requirements set* Performing a gap analysis between existing capabilities and those required to fulfill the required set of products and services* Using an Enterprise Architecture process to develop a target architecture inclusive of existing observation and modeling

systems, and which bridges the gap between existing capabilities and required capabilities* Selecting the most suitable technologies to instantiate the target architecture into a system-of-systems design* Complementing the system design with a set of well-defined processes and staff that can implement and operate the designed

system-of-systems* Estimating life cycle costs and developing operational and procurement budgets* Developing operational, training, and maintenance plans and procedures including defining required facilities and staffing* Assessing implementation and operational risks and developing mitigation plans* Developing a transition plan for existing systems and organizations to integrate into the target environment* Verifying the functional capabilities of the target system-of-systems including interoperability with other regional systems* Planning full deployment towards FOC

Conclusion

The paper outlines an approach to building a national U.S. IOOS that integrates existing ocean observing and modeling assetsusing a Service Oriented Architecture. Central to the realization of IOOS are the ratification of a set of metadata and interfacestandards, and the establishment of technical and operational governance structures. Complemented by a committed long-termfunding stream, the vision of IOOS as a federated system-of-systems bringing significant benefits to all its stakeholders includingthe society at large can be realized using technologies available today.

ACKNOWLEDGMENT

The author acknowledges the many members of the IOOS community for their interaction and exchange of ideas pertaining toIOOS, notably the staff at that National Ocean Service (NOS) in NOAA, the staff at Ocean.US, Philip Bogden of the Gulf ofMain Ocean Observing System (GoMOOS) and Southeastern Universities Research Association (SURA), Matt Thomas ofSoutheastern Universities Research Association (SURA), Andrew Lomax of Itri Corporation, and Brian Rothschild of the Schoolof Marine Science and Technology at the University of Massachusetts.

The author also acknowledges the contributions made by his colleagues at Lockheed Martin Corporation's Transportation andSecurity Solutions company in Rockville, MD.

REFERENCES

[1] The National Office for Integrated and Sustained Ocean Observations Ocean.US, "The First U.S. Integrated Ocean Observing System (IOOS) DevelopmentPlan", January 2006.

[2] The National Office for Integrated and Sustained Ocean Observations Ocean.US, "Data Management and Communications Plan for Research andOperational Integrated Ocean Observing Systems", March 2005.

[3] U.S. Commission on Ocean Policy, "An Ocean Blueprint for the 21st Century: Final Report of the U.S. Commission on Ocean Policy", September 2004,Chapter 26.

[4] The National Office for Integrated and Sustained Ocean Observations Ocean.US, "Implementation of the Initial U.S. Integrated Ocean Observing System",May 2003.

[5] Thomas Erl, "Service Oriented Architecture: Concepts, Technology and Design", Prentice-Hall.

0-933957-35-1 ©2007 MTS