Science requirements and the design of cabled ocean observatories

The ocean sciences are beginning a new phase in which scientists will enter the ocean environment and adaptively observe the Earth-Ocean system through remote control of sensors and sensor platforms. This new ocean science paradigm will be implemented using innovative facilities called ocean observatories which provide unprecedented levels of power and communication to access and manipulate real-time sensor networks deployed within many different environments in the ocean basins. Most of the principal design drivers for ocean observatories differ from those for commercial submarine telecommunications systems. First, ocean observatories require data to be input and output at one or more seafloor nodes rather than at a few land terminuses. Second, ocean observatories must distribute a lot of power to the seafloor at variable and fluctuating rates. Third, the seafloor infrastructure for an ocean observatory inherently requires that the wet plant be expandable and reconfigurable. Finally, because the wet communications and power infrastructure is comparatively complex, ocean observatory infrastructure must be designed for low life cycle cost rather than zero maintenance. The origin of these differences may be understood by taking a systems engineering approach to ocean observatory design through examining the requirements derived from science and then going through the process of iterative refinement to yield conceptual and physical designs. This is illustrated using the NEPTUNE regional cabled observatory power and data communications sub-systems. Mailing address: Dr. Alan D. Chave, Deep Submergence Laboratory, Woods Hole Oceanographic Institution, Woods Hole, MA 02543, U.S.A.; e-mail: alan@whoi.edu

ed levels of power and communication to access and manipulate real-time sensor networks deployed within many different environments in the ocean basins.These facilities, their real time or near-real time information flow, and the data archives associated with them, will empower entirely new approaches to science.In addition, ocean observatories will enable educational-outreach capabilities that can dramatically impact general understanding of, and public attitudes toward, the ocean sciences and science in general.
The crucial role ocean observatories will play in 21st century oceanography has received international recognition, and early programs are underway around the world (e.g., Beranzoli et al., 1998;Momma et al., 1998;Delaney et al., 2000;Glenn et al., 2000;Kasahara et al., 2000;Austin et al., 2002;Chave et al., 2002;Favali et al., 2002;Hirata et al., 2002;Schofield et al., 2002;Petitt et al., 2002;Beranzoli et al., 2003;Dewey and Tunnicliffe, 2003).Major ocean observatory infrastructure programs are under consideration in Japan (Advanced Real-Time Earth monitoring Network in the Area or ARENA; Shirasaki et al., 2003), Europe (The European Seafloor Observatory Network or ESONET; http://www.abdn.ac.uk/eco-system/esonet/), and the United States (Ocean Observatories Initiative or OOI; Clark and Isern, 2003).The largest component of the OOI is a US-Canada regional cabled observatory called NEPTUNE (North-East Pacific Time-integrated Undersea Networked Experiment) for which the Canadians received C$62M in late 2003.Almost all of the cited installations use submarine cables to link land to seafloor, and hence the remainder of this paper will focus on cabled ocean observatories.

A generic cabled ocean observatory
In an attempt to establish common terminology, a generic cabled ocean observatory structure will be defined.A comprehensive description of the hardware design and implementation of cabled ocean observatories may be found in Chave et al. (2004).A software or cyberinfrastructure framework for ocean observatories is described by St. Arnaud et al. (2004).
Figure 1 shows one or more sensors deployed in the water.A suite of sensors is the fundamental measurement device at an observatory, and is ultimately the source of a data stream.Sensors are part of, or attached to, instruments.Instruments are attached to instrument ports on an observatory node located on the seafloor via an access layer data communications connection (typically, RS232/RS422 serial or10/100BaseT Ethernet).The observatory node also supplies power (typically, 12 or 48 VDC) and may distribute accurate time using standard codes.Custom instrument ports may support special instruments with unique needs.Standard instrument ports are more generic.Ocean observatory nodes are connected to each other and to a shore station via a core layer data communications link (typically, high speed serial or Gigabit Ethernet via a backbone submarine fiber optic cable).The backbone cable also contains an electrical conductor, and provides power to the observatory nodes from shore with a seawater return path.An ocean observatory operations center monitors, maintains, controls, and manages the components of the obsevatory.
An observatory instrument control process is used by operators or guest scientists to control node instrument ports, instruments, and sensors.Core instruments are managed by the ocean observatory operator or their designees.Individual investigator instruments may be one of a kind, and are deployed on behalf of a guest scientist.The instrument data logging process gathers realtime or near real-time data (and sometimes instrument metadata) from instruments and stores it temporarily.This step may happen in the water, on shore, or both.The data archive process gathers/receives data and/or metadata from the instrument logging process or in some cases directly from the instrument itself.The data archive process may extract instrument metadata from the data stream, post-process the data stream, or manage it in some other way.In some ocean observatories, a streaming data process provides subscribers with real-time data from sensors/instruments.In most cases, the ocean observatory is connected to the Internet, and an observatory server provides scientists and the public with access to certain observatory services.

Ocean observatory design requirements
The commercial marketplace has driven the design of submarine fiber optic telecommunication systems to very high data rates using a Dense Wavelength Division Multiplexed (DWDM) physical layer implemented using comparatively simple, very high reliability submarine equipment.Electronic complexity is concentrated at a very small number of shore stations.Combined with advances in submarine cable installation and burial, the result is extremely reliable communications infrastructure.
Many of the principal design drivers for ocean observatories differ from those for conventional submarine telecommunications systems.First, ocean observatories require data to be input and output (i.e., switched and aggregated) at one or more seafloor nodes rather than at a few land terminuses.Second, ocean observatories must distribute a lot of power (typically, multiple kW per node) to the seafloor at variable and fluctuating rates to supply both seafloor instruments and the observatory hotel load.Third, science requires the delivery of accurate (typically, order 1 µs in an absolute sense) time to seafloor instruments which has no counterpart in the commercial world.Fourth, the seafloor infrastructure for an ocean observatory is inherently dynamic, and hence the wet plant has to be expandable and reconfigurable to meet changing science needs.Finally, because the wet communications and power infrastructure is comparatively complex, ocean observatory infrastructure must be designed for low cost maintenance and upgradeability.
Despite these differences, a key design driver in both ocean observatory and commercial telecommunications system design is reliability.A primary reliability measure is the probability that data will be received on shore or at another seafloor instrument or node from a given science instrument on the seafloor, and the least reliable infrastructure components in this path inevitably are the node power and communications electronics.As further discussed by Chave et al. (2004), an immediate corollary is that there may be no reliability gain from combining high cost, high reliability submarine telecommunications wet plant with lower reliability node electronic systems.
Taken together, these points suggest that the overall design of ocean observatories will be fundamentally different from that of submarine telecommunications systems.Understanding why this is true is a principal purpose of this paper, and is facilitated by taking a system engineering view of the ocean observatory design process.However, although design requirements differ between telecommunications and science systems, the high quality submarine fiber optic cables, joints, terminations, and wet hardware, as well as the installation and burial expertise of industry, are highly relevant to ocean observatory implementation.

The system engineering process
A system is defined as a collection of functional elements which work together to perform some defined set of functions.It consists of a hierarchy of sub-systems which taken in aggregate comprise the whole system.The observatory node in fig. 1 is one sub-system in the ocean observatory system, and may in turn be divided into a power sub-system, a backbone communications sub-system, an instrument interface sub-system, and so on.
System engineering is a management and engineering process which brings a system into being.Its development as an engineering discipline grew out of the need to manage and integrate increasingly complex technological projects.Recent texts on the subject include Eisner (1997), Blanchard (1998), andStevens et al. (1998).Neither the system engineering process nor its procedures are uniquely defined, but one common implementation is contained in Military Standard 499B (1991).The main stages of this standard as outlined here are typically included in any well-designed system engineering implementation.
Figure 2 is a top-level view of the Mil Std 499B system engineering process.It contains three main stages: 1) requirements analysis; 2) functional analysis/allocation; 3) synthesis; and 4) a continuous, cross-cutting system analysis and control phase.
The requirements analysis stage focusses on two types of requirements: user and performance.In the context of an ocean observatory, the user requirements flow from science needs, and are identified through the analysis of a wide range of use scenarios incorporating representative suites of sensors and platforms.The goal is to identify and define the set of functions that the system must do to meet the user requirements, and to place bounds on how well these functions must be carried out.These are called the functional and performance requirements, respectively.In the sequel, these will collectively be referred to as the science requirements.
The second system engineering stage is functional analysis/allocation, in which the objectives defined by the science requirements are decomposed into a set of lower-level functions and performance allocations are applied to each of them.The functional interfaces and a candidate functional architecture are defined.This process is iterative, and constant verification that the science requirements are being met must be achieved.The third system engineering stage is synthesis, in which all elements of the functional design are transformed into a physical design.Synthesis begins at a concept design level, then passes on to a preliminary design level where risk is mitigated by testing key parts of the hardware and software, and then passes to a detailed design level where full prototypes are constructed.This stage is also iterative, both with the preceding functional analysis/allocation stage to ensure that the required functionality is being provided and with the requirements analysis phase to verify that the science requirements are being met.
The cross-cutting phase of the system engineering process is system analysis and control.This consists of a set of trade-off studies comparing the feasibility, performance, and cost of alternative technical approaches along with a set of over-arching tasks to manage risk, configuration, and interfaces.Ongoing documentation and technical reviews are also a system analysis and control function.
The focus in the remainder of this paper will primarily be on the requirements analysis phase and how this leads to functional and physical implementations of an ocean observatory system.As an illustration of the refinement process using trade studies, two selected elements will be examined in detail.

Science requirements for a cabled ocean observatory
In the sequel, selected science requirements for the NEPTUNE Regional Cabled Observatory (RCO) will illustrate the system engineering process used to derive them.NEPTUNE is conceived as a multi-node regional observatory comprising 26 seafloor science nodes with two shore connections covering the Juan de Fuca plate off northwest North America (Delaney et al., 2000).Figure 3 presents a notional layout for NEP-TUNE.The NEPTUNE science requirements are broad and generic, and could easily apply to oth-Fig.3. Map illustrating the notional topology of the NEPTUNE regional cabled observatory.The letter labels delineate specific nodes, while the numerical labels give the optical link lengths in km.
er installations such as the planned ARENA system in Japan or components of ESONET in Europe.In the feasibility study for NEPTUNE (NEPTUNE Consortium, 2000), an initial survey of the range of science that could be accomplished with an RCO was carried out, including the development of use scenarios and an assessment of the characteristics of instruments that might be installed.This serves as initial input to definition of the science requirements.A similar procedure was used to define the science requirements for GEOSTAR, as documented in Thiel et al. (1994).
As should be clear from fig. 2, deriving the science requirements is an iterative process.At the outset, functional and performance requirements may be posed by the user community that cannot be met with available technology, or even that may not be consistent with known physics.The inner requirements and design loops combined with the outer verification loop (fig.2) serve to improve the initial requirements and eliminate such problems.The science requirements presented here are the product of several such stages of iterative refinement, but are still considered to be in draft form until the synthesis stage passes from the concept through the detailed design levels.
The science requirements to be discussed are divided into general, power network, and data communications network categories, and are the most mature ones for NEPTUNE.There are numerous other categories in the RCO, including time distribution, observatory control, science instrument interface, user/observatory interaction, data management and archiving, security, operations, and reliability which will not be discussed.

Design principles
The design principles are overarching requirements which apply to all parts of the RCO, and serve as guiding principles through the entire design process.There are ten design principles for the RCO, each of which is denoted by a keyword.
The first and second design principles establish life and cost goals for the RCO.The lat-ter is important, as virtually all ocean observatory installations will be cost-capped.Life cycle cost is defined as the sum of expenditures for Research, Development, Test, and Evaluation (RDT&E), procurement and installation, and Operations and Maintenance (O&M) over the design life of the system.
A.1.Lifetime -The RCO shall operate, with appropriate maintenance, for a design life of at least 25 years.
A.2. Cost -The RCO shall be designed to minimize the life cycle cost.
The third through sixth design principles state that all components of the RCO have to be capable of reconfiguration or extension to adapt to a changing mission after installation, and that the basic infrastructure has to be designed to be flexible and able to accommodate changes in technology over time.Static designs would not suffice, and technologies which inherently limit the number of nodes that can be implemented over a given part of the RCO would not be appropriate.
A.3.Reconfigurability -The RCO shall allow all resources to be dynamically-directed where science needs and priorities dictate.
A.4. Scalability -The RCO shall be expandable, so that additional science nodes which meet the observatory reliability goals can be placed near or at locations of interest that may develop in the future.
A.5. Extendability -The RCO shall support individual instruments or clusters of instruments at sites up to 100 km away from the science nodes with possibly reduced power and communications capability and reliability.
A.6.Upgradeability -The RCO shall be upgradeable to accommodate future technology improvements.
The seventh and eighth design principles establish reliability and fault tolerance goals for the RCO.These are quantified later in the science requirements, and are intended to establish the manner in which they will be derived.The reliability design principle states that the integral probability of data transmission from seafloor node to shore (or another seafloor node) will be the principal measure of RCO reliability.A design which is highly reliable in some parts of the system but offers no improvement in the total probability of instrument connectivity is not inherently superior.Other criteria, such as life cycle cost, must be applied to compare designs with similar reliability.
A.7. Robustness -The RCO shall utilize fault tolerant design principles for both hardware and software to minimize potential single points of failure, A.8. Reliability -The primary measure of RCO reliability shall be the probability of being able to send data from any science instrument to shore and/or to other science nodes, exclusive of instrument functionality.
The ninth design principle specifies that all components of the RCO have to be designed with a forward-looking rather than a status quo perspective in order to meet future science needs.
A.9. Futurecasting -The RCO shall have functionality and performance significantly beyond that required to support current use scenarios so that experiments and instruments that may reasonably be anticipated to develop over the expected life of the facility can be accommodated.
The final design principle states that all of the designs for hardware and software elements of the RCO shall be public insofar as possible.An ocean observatory should be viewed as an end-to-end scientific instrument, and hence black box elements between instrument and user are not appropriate.
A.10. Open design principle -The RCO hardware designs and specifications shall be freely and openly available, and all software elements shall be based on open standards to the greatest extent possible.

Power network
The power network design requirements are specific to the distribution of power to supply both the RCO infrastructure and seafloor sensors.Where specific numbers appear, these represent requirement and design loop refinement based in particular on the voltage and resistance rating of standard submarine fiber optic cable.The premise is that the design of custom cable would be prohibitively expensive, and the additional weight from adding copper to reduce the intrinsic resistance per unit length of the cable would lead to installation and handling problems.
The first and second requirements specify respectively that primary requirements are maximizing the average and peak power to all nodes simultaneously and maintaining the flexibility to direct more power to a small number of selected nodes.Designs which either inherently favor some nodes over others or lack flexibility to allocate power would not be appropriate.
B.1.The power network shall provide the maximum average continuous user power equally to all nodes, with a goal of 5 kW.
B.2.The power network shall provide the maximum peak user power to as many nodes as possible, with a goal of 10 kW.
The third requirement states that the power system will always start up in a predictable manner.
B.3.The power network shall be in a known state upon power up.
The fourth and fifth requirements specify that minimizing the effect of faults (either physical faults on the backbone cable or power system problems) on science and localizing them when they occur are important science needs.
B.4.The power network shall be able to detect and localize infrastructure problems, including (but not necessarily limited to) shunt faults or breaks of the backbone cable, high resistance faults, and node power system failures.
B.5.The power network shall isolate failed sections of backbone cable or failed nodes such that the remaining operational nodes can function normally.
The sixth and seventh science requirements state that monitoring and allocating power at individual science nodes is a critical need.
B.6.The power network shall provide voltage and current monitoring functionality adequate to detect and localize infrastructure and user instrument problems, including (but not necessarily limited to) over-current faults in user and infrastructure loads and ground faults.B.7.The power network shall allow power delivery to all nodes and science ports to be scheduled and prioritized.
The final design requirement serves to protect both the infrastructure and attached science instruments from damage due to unwanted cur-rent flow through housings and connectors.An additional need to monitor instruments and connectors for ground faults appears elsewhere in the science requirements document.
B.8.All pressure cases, including support frames or assemblies electrically connected to them, shall be DC isolated from all signal and power circuits in the RCO.
Additional environmental requirements lead to detailed specifications for power supply ripple, total harmonic distortion, and the like during the design cycle.

Data communications network
The data communication network science requirements are specific to the backbone data transport for an RCO.Specifications for the link between instruments and the infrastructure are stated elsewhere.Where specific numbers appear, these represent requirement and design loop refinement based on forward-looking estimates of bandwidth and instrument needs.
From use scenarios and investigation of the communications requirements of a wide range of instruments, a preliminary estimate of both the aggregate bandwidth of an RCO and the maximum data rate for an individual instrument can be derived.The aggregate bandwidth can then be scaled by a large factor (10 or more) to allow for future growth and technological development.One significant unknown is the maximum instrument data rate; except for high density television (HDTV) operating in an uncompressed mode at a data rate in excess of 1 Gb/s, it is difficult to identify anything which requires more than a few times 10 Mb/s.Since it is unlikely that extensive use of uncompressed HDTV will be required, the total data rate does not reflect this number.The alternative is to scale the bandwidth upward in C.1, significantly raising system costs.Note that C.2 states the data rate that must be delivered to the user at all times in the RCO life cycle to allow for aging effects.
C.1.The data communication network shall support an aggregate backbone data rate of at least 8 Gb/s.C.2.Each data communication node subsystem shall support an aggregate instrument data rate of at least 1 Gb/s exclusive of overhead for system functions such as (but not necessarily limited to) framing or re-transmission due to errors, at all times during the observatory life cycle.
The third requirement states that the data communications system will always start up in a predictable manner C.3.The data communication network shall be in a known state upon power up.
The fourth science requirements state that the data communications system needs to be automatically fault-tolerant.Most standard data communications systems meet this requirement automatically.
C.4.Each data communications node subsystem shall automatically reconfigure itself to suppress fault propagation, and shall automatically recover from faults.
The fifth and sixth science requirements specify a need for remote monitoring and control of the data communications infrastructure.C.5 is met automatically by most modern data transport protocols.C.6 anticipates the standard use of backdoor access into communications hardware, and flows from reliability requirements and the remote deployment of complex hardware on the seafloor.
C.5.Each data communication node subsystem shall be monitored and controlled over the data communication network using standard protocols.
C.6.Each data communication node subsystem shall be monitored and controlled over a high reliability, auxiliary channel.
The seventh science requirement states that the data communications network must be dynamically changeable to accommodate changing science needs.
C.7.The data communication network shall be remotely re-configurable so that data transmission to and from each node can be scheduled and prioritized.
The eighth science requirement specifies instrument data rates that must be supported.These are stated in more detail in the instrument interface specifications.
C.8.Each data communication node subsystem shall support a maximum data rate from each instrument of 100 Mb/s, and for at least one instrument or secondary node at 1 Gb/s, us-ing standard Internet protocols, including (but not necessarily limited to) TCP/IP and standard application layer protocols.
The final two data communications science requirements are derived from future-casting the current and emerging state-of-the-art in sensor network development in accordance with A.9.While the initial expectation for NEPTUNE was that communications would only occur between numerous seafloor instruments and a few land sites, recent developments in sensor networks suggest that this is very likely to change in the future.The design of distributed, intelligent, selforganizing sensor networks (e.g., «smart dust», «sensor webs») based on low cost, miniaturized (i.e.MEMS technology) sensors is an exciting and rapidly evolving area of research, and it is reasonable to expect that this will port to the seafloor in the not very distant future.Implementation requires minimum latency inter-node and inter-sensor communications paths on the seafloor in addition to links to land.
C.9.The data communication network shall facilitate intra-node, peer-to-peer communication by user instruments with the minimum possible latency commensurate with direct inter-instrument propagation delay.
C.10.The data communication network shall facilitate inter-node peer-to-peer communication by user instruments with the minimum possible latency commensurate with direct inter-node propagation delay.

Implementation and trade-study refinement
The iterative refinement of the science requirements and concomitant development of the functional and physical designs is complex and multi-faceted, and it is nearly impossible to describe the entire process.Instead, two illustrative examples will be given for the power and data communications systems, respectively.

Parallel versus serial power system
The technical issues surrounding the choice of serial or parallel power for NEPTUNE are described in Howe et al. (2002).Series connections of terrestrial sources and the fixed loads at seafloor optical amplifiers (along with associated I 2 R losses on the submarine cable) with a single seawater return path is always used for standard submarine telecommunications systems.Parallel connections of the loads, in which each optical amplifier would have a seawater ground connection, has not been used, and in fact appears to offer no advantages in this application.
For a serial power meshed system such as NEPTUNE (fig.3), additional complexity is posed by the need to regenerate the power twice or more at branches and for active reconnection to handle faults.Hardware to implement these functions does not currently exist, although there appear to be no overwhelming obstacles to constructing it.Perhaps more significantly, because power must be conserved at a branch splitter, there is no efficiency gain to branching with serial power.By contrast, a parallel power system is easy to branch and gains efficiency when there are multiple paths to each load.In addition, a parallel system inherently has a higher power capability because the I 2 R losses are always lower due to the use of multiple rather than a single ground.However, fault detection on a branched parallel system is inherently more complex due to multiple paths to a break.This can be mitigated by including a capability in the nodes to isolate each section of cable.
These observations about ease of branching and power delivery limits, as well as consideration of the voltage and current capabilities of commercial-off-the-shelf submarine fiber optic cable, led to the decision to utilize a parallel rather than a serial power system for NEP-TUNE.Meeting science requirements B.1 and B.2 would be much more difficult if not impossible using a serial power system for a large meshed system like NEPTUNE.

Meshed network versus star data communications architecture
The NEPTUNE data communication design is based on an implementation of Gigabit Eth-ernet using a DWDM physical layer to provide up to 16 bi-directional Gb/s channels over a single pair of optical fibers.The NEPTUNE backbone topology (fig.3) is meshed, and the communications system gains reliability from redundant paths, as is also true for the Internet.There are multiple arguments for this design approach, as reviewed by Maffei et al. (2003).
An alternative approach has also been considered based on a star topology, in which each seafloor node communicates with each shore station using a single pair of wavelengths in a DWDM system, but does not communicate directly with any other node except through a shore station.This network topology was used in the early days of data networking when routing hardware was primitive and costly, but is obsolete and no longer used.The star network would be implemented using point-to-point SONET data transport with custom optical add/drop multiplexing at each node and submarine telecommunications-standard optical amplifiers to provide path gain.The premise was that the extreme reliability of submarine optical amplifiers (typically, of order 10 FITS; 1 FIT equals 1 failure in 10 9 h) would produce significantly higher data communications network reliability.
A complete comparison of these two approaches is complex, but four simple observations can be used to derive a first order version: 1) To lowest order, the star network is more expensive than the Gigabit Ethernet system by the cost of 50+ submarine optical amplifiers and the non-recurring engineering required to implement optical add/drop multiplexing, for a total difference of about US$30M.
2) Based on statistical modeling, the data network reliability based on the criterion of science requirement A.7 is slightly better for the Gigabit Ethernet approach, although the difference in barely significant.The much higher backbone reliability of the star network approach does not translate into higher overall reliability because the node electronic reliability is orders of magnitude lower.
3) The failure rate of individual node SONET electronic systems for the star network approach is about 3 times higher than that of high quality Gigabit Ethernet hardware.This translates into higher O&M costs as more fail-ures will occur per unit time, presuming that all failures are repaired as soon as possible after they occur.Given the higher procurement costs of the star network design, the life cycle costs of this approach will be higher, and probably much higher, than the Ethernet implementation.
4) The inter-node latency of the star network design will depend on the actual pair of nodes being considered, but will in general be high because of the necessity to transit to shore and back to the seafloor.A typical value will be tens of ms with no tendency to be lower for adjacent than sub-adjacent nodes.By contrast, the adjacent inter-node latency of the Ethernet system approaches the goal in criterion C.9, with sub-adjacent node latency being nearly integral multiples of this value.
Taken in aggregate, these observations mitigate against the star network and in favor of the Gigabit Ethernet approach in several ways.
These examples indicate that the design of ocean observatories is a complex engineering process, and can be facilitated using a systems engineering approach based on requirements derived from science needs and use scenarios.

Fig. 1 .
Fig. 1.Cartoon illustrating the major components of a cabled ocean observatory.See text for discussion.Core and PI (Principal Investigator) instruments represent a preliminary classification of sensors that will be refined in the process of system development.

Fig. 2 .
Fig. 2. Cartoon illustrating the major stages and phases of the Military Standard 499B system engineering process.See text for discussion.