3
Architecting and Building the Naval C4ISR System

3.1 PERSPECTIVE

The first two chapters of this report discussed the national security environment and the naval roles and missions within that environment as these drive the capabilities needed in the future for naval command, control, communications, computers, intelligence, surveillance, and reconnaissance (C4ISR). The Naval Services, like their sister Services and the broader Department of Defense (DOD), are treating C4ISR as an integrated, mission-driven enterprise for achieving the transformational vision of network-centric operations (NCO). This chapter discusses the evolution to NCO in terms of both architectural and implementation imperatives.

Section 3.2 reviews the network-centric vision in terms of its fundamental paradigms for handling information, its reliance on the enabling infrastructure being provided by the Office of the Secretary of Defense (OSD), and the requisite system attributes and design principles that must be applied to the components of the C4ISR architecture. Section 3.3 then reviews the ongoing architecting activities of the Naval Services. Section 3.4 focuses on the need for authoritative Department of the Navy architectural guidance and on mechanisms for translating this guidance into fielded capabilities. The chapter concludes with findings and recommendations in Section 3.5.



The National Academies | 500 Fifth St. N.W. | Washington, D.C. 20001
Copyright © National Academy of Sciences. All rights reserved.
Terms of Use and Privacy Statement



Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.

OCR for page 70
C4ISR for Future Naval Strike Groups 3 Architecting and Building the Naval C4ISR System 3.1 PERSPECTIVE The first two chapters of this report discussed the national security environment and the naval roles and missions within that environment as these drive the capabilities needed in the future for naval command, control, communications, computers, intelligence, surveillance, and reconnaissance (C4ISR). The Naval Services, like their sister Services and the broader Department of Defense (DOD), are treating C4ISR as an integrated, mission-driven enterprise for achieving the transformational vision of network-centric operations (NCO). This chapter discusses the evolution to NCO in terms of both architectural and implementation imperatives. Section 3.2 reviews the network-centric vision in terms of its fundamental paradigms for handling information, its reliance on the enabling infrastructure being provided by the Office of the Secretary of Defense (OSD), and the requisite system attributes and design principles that must be applied to the components of the C4ISR architecture. Section 3.3 then reviews the ongoing architecting activities of the Naval Services. Section 3.4 focuses on the need for authoritative Department of the Navy architectural guidance and on mechanisms for translating this guidance into fielded capabilities. The chapter concludes with findings and recommendations in Section 3.5.

OCR for page 70
C4ISR for Future Naval Strike Groups FIGURE 3.1 A generalized view of the fundamental future naval C4ISR network-centric information architecture. NOTE: The local area networks, shown on the right as four clouds, may or may not have routers and communication paths distinct from the Global Information Grid. SOURCE: Adapted, with permission, from C.J. Grant, J.A. Krill, and R.T. Roca, 2005, Transforming a Sensor Network from a Closed System to Part of a Common Network Architecture (U), Johns Hopkins University, Applied Physics Laboratory, Laurel, Md. Copyright 2005 by the Johns Hopkins University/Applied Physics Laboratory. All rights reserved. 3.2 THE FUNDAMENTALS OF A NETWORK-CENTRIC INFORMATION ARCHITECTURE Figure 3.1 presents a generalized view of the naval C4ISR architecture recommended by the committee: an Internet-like core network with various information sources and users and user enclaves (e.g., communities of interest for strike warfare, theater air defense, and undersea warfare) connected to the core, and therefore to each other, via an interoperable mechanism. Various enabling network services are provided, by and through the network, to the users (a service-oriented architecture approach). There is considerable distance between this vision and today’s capabilities and paradigms—indeed, a technologically enabled revolution is implied in the

OCR for page 70
C4ISR for Future Naval Strike Groups vision. It is also noted, however, that tangible progress has been demonstrated in current military operations and that near-term opportunities for substantial further progress are emerging as new, core capabilities are fielded. 3.2.1 The Network-Centric Vision The Global Information Grid For the broadly defined information architecture, the Global Information Grid (GIG)1 and its attributes are essential. First, the GIG is defined to include not only the communications network for the DOD, but also the network services, the data and their storage, and the applications and their user interfaces required for information to flow and to be used. Major interfaces with the GIG are both the users and the sources of information; the intelligence, surveillance, and reconnaissance (ISR) sensors and associated data-processing systems that transform sensor data to calibrated, useful products; and weapons platforms and command-and-control (C2) and intelligence facilities. Today’s GIG contains major elements that rely on broadcast techniques for information distribution to various C2 and fusion centers, and it uses application integration to then allow collaboration among users. The envisioned future, network-centric GIG will not have such elements but rather will have all sensors and users interconnected by a network, without dependence on dedicated sensor-to-user circuits or information intermediaries. As such, the future GIG will provide an information-sharing architecture to enable network-centric operations. The major program components of the GIG’s enabling information infrastructure are shown in Figure 3.2, along with their initial operating capability (IOC) milestones (as of this writing). The Communications Foundation The future GIG will have many tiers of communications, data storage, and applications, all operating together. At the core will be a shared, fiber-based, terrestrial communications network with effectively infinite bandwidth. The initial Global Information Grid–Bandwidth Expansion (GIG-BE) program2 is delivering 10 gigabits per second (Gbps) of Internet Protocol (IP)-based communications to each of about 100 nodes around the world connected by fiber-optic 1   U.S. Joint Forces Command. 2001. GIG Capstone Requirements Document (CRD) JROCM 13-01, Norfolk, Va., August 30. 2   Global Information Grid-Bandwidth Expansion Program Office. 2002. GIG Bandwidth Expansion (GIG-BE) Derivative Requirements Document (DRD), Version 3.0, December 17, Washington, D.C.

OCR for page 70
C4ISR for Future Naval Strike Groups FIGURE 3.2 Future core Global Information Grid (GIG) capabilities and the year of initial operating capability (IOC) for each, as identified by the Office of the Secretary of Defense (Networks and Information Integration). cables. This bandwidth is being divided among various levels of classification using the Multi-Protocol Label Switching (MPLS) protocol, which allows virtual circuits to be formed within the IP network when they are required. For about twice the investment in the initial GIG core, the bandwidth could be increased by a factor of 1,000, which is a good approximation of infinite capacity compared with today’s operations. Extensions between this fiber-based core to mobile users, including previously disadvantaged users at the tactical edge, will be provided by program capabilities now being acquired. In about 10 years, the Transformational Satellite (TSAT) system will extend the core and will allow the same 10 Gbps rate, or multiples of that rate if more channels are used simultaneously. Information will enter the network from sensors sending back data via the satellite system or from the core network to routers within the TSAT system to deliver information to deployed users via TSAT’s radio frequency (RF) downlinks, whether the users are on the move or not. Antennas of about 18 in. in diameter will support rates greater than the rate that a current fusion center derives from its numerous 8 ft antennas (approximately 10 megabits per second [Mbps]). While no user will get 10 Mbps continuously, the system will allow several tens of thousands of users to

OCR for page 70
C4ISR for Future Naval Strike Groups get burst rates of 10 Mbps sharing one satellite.3 Multicast will also be available, to broadcast the Cable News Network (CNN), as an example. For platforms not able to use an 18 in. antenna to connect with a satellite and for individual combatants, the Wideband Network Waveform (WNW) in the Joint Tactical Radio System (JTRS) will be available to form networks to extend the communications from TSAT terminals to the surrounding area, supporting tactical enclaves. By that time, there should also be multiple commercial systems available to connect with the GIG as well; however, mission-critical network-centric operations should only use commercial satellites as a last resort, owing to the questionable availability of those resources in time of need. The Network-Centric Information-Handling and -Processing Paradigm Today a fusion center or user must process data received from the broadcast channels in order to combine the information from the various channels. By contrast, the new GIG will perform significant processing within the core network; thus, users will often be pulling only answers to themselves, not potentially voluminous data that must still be processed. Therefore, the sharing of the satellite bandwidth as described above is realistic; multiple users would be asynchronously receiving tens of seconds of “only answers” at 10 Mbps rates. However, high-quality video such as high-definition television (HDTV) mandated by the National Geospatial-Intelligence Agency (NGA) for persistent surveillance and videoteleconferencing will require continuous service. Located on the core network will be three types of nodes in addition to that for users: nodes for data sources, applications, and value-added service providers. Every ISR system (as well as other sources) will post its data on the core network. These data would then be available for users to combine with their chosen applications, in combinations managed by the value-added service providers, for obtaining answers to their information needs. Data will be posted without any knowledge of who will use it, and applications will use the data available on the network no matter where it comes from, to solve the problem of the moment, without knowing a priori the data source or its location. As noted, every sensor, platform, and user will communicate directly with the network, not with another sensor, platform, or user. (As also noted, some users may have local-area networks with a gateway to wide-area connectivity.) Hence, the term network-centric aptly describes such a system. Sensors not directly connected to the core network will use feeder systems as tails of the core, such as TSAT, the Defense Information Support Network (DISN), or other special networks, but the goal is to get the data from the sensor posted on the network for use by all users. 3   Until TSAT is deployed, Navy ships will connect to the GIG using the satellite communications (SATCOM) systems discussed in Chapter 6, “Communications.”

OCR for page 70
C4ISR for Future Naval Strike Groups Likewise, users reach back to the network to get the data they need, processed by the applications they choose. The value-added services will provide tailored answers to problems so that each user does not have to invent solutions to every problem. Examples of such tailored answers include target tracking and identification data, or current information about a specific location including weather, pictures of the locale, analysis of threats in the area, and so on. All such information will be pulled by the user in that location when needed. A user needing target-tracking data in an area might use one value-added service that searches the network for all applicable data and algorithms and defines a business process to integrate them so that a track array will be produced with the minimum number of tracks consistent with the data. Another user might use a different value-added service to derive a track array with a minimum number of leakers (missed targets), consistent with the data. All users will know where they are, what their limitations in time and communications are, and what their tasks are; therefore, they will be able to tailor their individual reach-back requests to the network for the specific conditions at the time. Such a network will be service-oriented, with the network manager providing such services as the discovery of potential new users or sources, mediation between various data formats, the discovery of data and applications to solve problems, and the provisioning of the appropriate security keys to allow access to the data required. While all information architectures have relied to date on the direct transmission of information from a source to a user to operate, there are stories—some noteworthy and operationally damaging—about the data that were present some-where but just not available to the user who needed them at a particular time. The envisioned network-centric architecture is designed to deal with such issues; it is a sharing architecture, with all data available to all users at all times, subject to access controls. The network operates in a user-pull fashion, not in a push-to-the-user manner as in the past. If the equivalent of today’s “smart push” is demanded by latency or other considerations, this would be implemented through a publish-and-subscribe agreement with a value-added service provider. 3.3 IMPLICATIONS OF NETWORK-CENTRIC ARCHITECTURES FOR THE DEPARTMENT OF THE NAVY The achievement of a network-centric capability requires much more than the development of a short list of communications programs. While core elements of the GIG network will be provided by various elements of the DOD, the Department of the Navy must both interact with the network and provide supporting services, such as tails to the network using the Mobile User Objective System (MUOS) and naval-unique value-added applications services. Additionally the Assistant Secretary of Defense for Networks and Information Integration (ASD[NII]) has promulgated guidance that defines the GIG, its interfaces, and a set of design principles and objectives that are elaborated below. The Department of the Navy should lead

OCR for page 70
C4ISR for Future Naval Strike Groups the evolution of that enterprise guidance, including the development of selected standards that are most important for its mission-driven interfaces. For the Department of the Navy to manage the multiple programs and their interfaces with the GIG requires that a set of network-centric architectural imperatives be accepted across all activities of the Naval Services and implemented in a consistent fashion in order to move to the new environment described briefly above. These architectural “rules of the road” need to be consistent with the guidance being promulgated by the DOD and others and need to be internalized sufficiently by the Naval Services both to direct programs and to support informed deviations and waivers only when an operational case is compelling. For example, communications to Trident submarines to transmit Emergency Action Messages certainly should not be forced into this new architecture. There will be other, less-obvious cases that will require detailed knowledge of the trade-offs when waivers from standards are requested, because each such waiver will require that special-purpose work-around solutions be developed in order for the system to interface with the GIG. Successful enterprise evolution demands a strong management commitment to integration and resource balancing across programs. The committee does not see evidence of such Department of the Navy processes for network-centric architectures—that is, processes sufficient to change how programs are progressing, or to shift resources systematically from programs that will never fit into the network-centric environment to those that can accelerate to it or transition in that direction. Further, there is the opportunity to exploit the enabling capability that is emerging. For example, by the end of 2005, the fiber-based core GIG network will be operational, with very few applications to exploit its full capability. Should not the Department of the Navy be working to install systems at fleet command centers that would dramatically change how imagery information flows from the NGA to the user? The NGA will be posting images on the network: will the Navy be pulling those required to perform its mission and working on them even as it waits for the normal NGA processing cycle to deliver the results that NGA’s business process calls for, whether or not these are tailored to the naval needs? The committee is aware of no such plan despite the fact that this represents a significant opportunity to move toward network-centric operations. 3.3.1 Network-Centric Imperatives This section addresses network-centric imperatives or first principles—that is, “How do you recognize a net-centric program if you see it?” The items listed below, taken from the ASD(NII) “Net-Centric Checklist”4 are the beginning of 4   Office of the Assistant Secretary of Defense for Networks and Information Integration, Department of Defense Chief Information Officer. 2004. Net-Centric Checklist, Version 2.1.3, May 12. This list represents a best-current-attributes summary. As technology protocols and standard practices change, these attributes will change.

OCR for page 70
C4ISR for Future Naval Strike Groups the list of attributes that will define the GIG and the infrastructure with which the Naval Services must interface and to which they must contribute in support of both naval and joint missions. The naval forces should maintain an active science and technology (S&T) program to understand and help shape evolving attributes. The committee believes that these attributes, properly applied to naval systems and procedures, will allow the Naval Services to achieve much of the order-of-magnitude improvement in performance promised by network-centric operations. It is acknowledged, however, that some fraction of the time (perhaps 10 to 20 percent), these will be the wrong attributes to force on a system. Trade-offs will sometimes be required to achieve the low latencies needed for fast tactical response, as Chapter 2 addressed in its discussion of mission-cycle time. This point is also addressed in the companion Naval Studies Board (NSB) report, FORCEnet Implementation Strategy.5 Therefore, for the Department of the Navy to implement and then operate an effective management arrangement to achieve network-centric capability, there is a requirement either for acceptance of these attributes as described or for some other set that includes these plus others, customized to naval needs when (and only when) required. The process must provide for both proposed changes to DOD guidance and a review of waiver and deviation requests within the Department of the Navy. Internet Protocol, Version 6 (IPv6) Adoption. Does the system route packets across all information paths using routers, without dedicated circuits? The basic premise of network-centric systems is the use of shared infrastructure using IP and routers. Without this attribute, the system will not operate with unknown other systems; operating with other systems is exactly the point of a network-centric system: to use whatever information is available, no matter where it comes from. This test must be applied to the applications in the system as well as to the communications, and the difficulty of moving to IPv6 will be greater for applications than for communications. However, the transition needs to be made to allow the mobility, security, and scalability required by the GIG. Encrypted information end to end (“black core”). Are the data encrypted before entering the GIG and its tails, and do the data stay encrypted at all times? If not, the entire GIG will not be able to solve the information assurance (IA) problem, and therefore the enterprise system will not reach its full network-centric potential. For instance, there are arguments in favor of passing special bits that would be used for technical control or quality of service although the bits are not black; such bits would threaten IA integrity unless restricted to isolated enclaves. Approval of special provisions need to be accomplished by the GIG system manager and should not be delegated. 5   National Research Council. 2005. FORCEnet Implementation Strategy, The National Academies Press, Washington, D.C.

OCR for page 70
C4ISR for Future Naval Strike Groups Is the system using IA equipment from the High Assurance Internet Protocol Encryption (HAIPE) family? This is the family of equipment being created under National Security Agency leadership that will provide end-to-end IA for the GIG. Data-centricity. Is the system data-centric, not applications-centric? Are the data available to be used by other applications in other systems at the same time that the applications within the system are using the data in accordance with the business process model for the system? Are the data properly labeled, using metadata tagging such that other systems and applications can find the data to use? Do the applications interface with one another by posting data to be used by the next application, or are the interim results hidden within the business process? The concept is to post all source data and the results of application operations, in addition to e-mails or reports written by users after they see the results, for others to use as well. For sensor outputs, for example, the source data should be made available as soon as they are usable by an application—that is, calibrated and tagged with metadata. A first application might be a scan of the entire scope of the source data to find likely items of interest, which are then assigned for further processing. This identification of points of interest would also be posted to the network. Only handle information once (OHIO). Is each element of information available on the network in only one place, with the originator responsible for its quality and availability, as well as for describing these attributes in the metadata? While the originator of information might use other sites for backup and survivability, the users of the information should all be able to access it at its origin on the network, thus eliminating the problem of data synchronization across multiple databases and applications. Post in parallel. Are all data made available to every user on the network at the same time? Before an application is begun that might filter the data in some way, the data should be made available to others on the network to allow other applications to be applied. For example, when the Defense Support Program (DSP) detects a hot spot on Earth, those data today are not operationally available to any application other than the one that then does scan-to-scan correlations to determine if the hot spot is moving; if it is moving, the likelihood that there is a missile in powered flight increases. This process continues until the sensor detects no more heat in the area, and a missile report is made or not on the basis of the application’s calculation. Because of the seriousness of a potential false alarm indicating that a missile is in flight and threatening some vital area, this application does not report until it has used all information available. In contrast, a user wishing to attack the missile’s Transportable Erector Launcher (TEL) is tolerant to false alarms, but not to delays in the cue that a missile might have been launched from a given area. If the data are not posted in parallel, they will never meet the requirement of the TEL chaser. Smart pull. Does the system allow users to control the process by choos-

OCR for page 70
C4ISR for Future Naval Strike Groups ing the value-added service that suits their needs? Is this a smart-pull system under the control of the user? Today, almost all systems are smart-push systems—that is, the originator of the data has a business process that meets his or her requirements, and only those data that meet the criteria of the given business process are transmitted, usually via a broadcast so that any user who might be interested will receive the data. But what of the case in which the predefined business process filters out data to maintain some timeliness requirement? A user might need those data, even though no such need was originally conceived. This capability for information to be used by unknown and unforeseen users is a major cause of the expected (and partially demonstrated) operational performance improvements available from network-centric operations. As noted, the publishand-subscribe paradigm, in cases involving needs that can be forecast a priori, is viewed as a special case of smart pull. Application availability. Are multiple applications also resident on the network with proper identification to allow a value-added service to find them and use them in different ways that satisfy new user requirements? It is important that all applications be available on the network; otherwise, when a collaboration session is created, the participants might be looking at the same data through different filters. Any collaboration will need to identify the application to be used, such as choosing between the minimum-track and minimum-leakage solutions discussed above. Dynamic allocation of access. Can new users, new data sources, new applications, and new value-added services be added to the network quickly and efficiently by the dynamic allocation of access using over-the-air key distribution for IA devices? Can an individual who is a cook in the morning have access to information about where the potatoes are in the morning and, when doing guard duty at night, access to the sensitive compartmented information (SCI) data concerning the location of force protection threats in the area? Of course access needs more than just a job justification, but does the system allow such dynamic allocation of access? 3.3.2 Relevance of Network-Centric Architecture for the Department of the Navy The committee’s view is that the articulation of fundamental attributes and design principles of the information architecture is central to guiding individual programs and their collective capability toward the network-centric vision. As already embedded in the Department of the Navy strategy, the adoption of the items listed above, with modifications and additions to recognize particular naval needs, is regarded as crucial to success. With this discussion as a foundation, the sections below develop findings and recommendations regarding the further development of architectural guidance and the establishment of strengthened technical and management mechanisms to translate this guidance into fielded capability.

OCR for page 70
C4ISR for Future Naval Strike Groups 3.4 THE STATE OF THE NAVAL C4ISR ARCHITECTURE The naval C4ISR architecture is being developed in the context of the capabilities-based planning approach described in Chapter 1, in response to the needs of the naval missions described in Chapter 2, and according to the network-centric vision described above. In particular, the committee observed that the Assessment Division of the Deputy Chief of Naval Operations for Resources, Requirements, and Assessments (N81) is executing a capabilities-based approach to resource planning aided by campaign models. These models attempt to include the effects of C4ISR as well as those of aerospace, surface, and subsurface platforms and of threat systems. While C4ISR modeling is a notoriously difficult problem requiring a continuing investment in improved modeling technologies and the verification and validation of models, N81 is using the current state of the art. The capabilities-based approach has the potential to allow C4ISR systems to compete for resources with platforms on a fair basis and to provide a more rational approach to resource allocation trade-offs between alternative C4ISR systems. However, it is not clear to the committee that the Department of the Navy has implemented a successful capabilities-based approach to acquisition management—one based on clear and consistent architectural principles with enforceable, consistent guidance and one that exercises trade-offs that are horizontal, crossing program boundaries. Rather, the required building blocks are being developed and fielded in the vertical world of programs, with overarching guidance being issued from multiple sources, although there are some convergence efforts attempting to deal with this problem, such as that of the Program Executive Office for Integrated Warfare Systems (PEO/IWS). 3.4.1 Naval Architecture and Acquisition Context The acquisition of naval C4ISR systems is the responsibility of the Assistant Secretary of the Navy for Research, Development, and Acquisition (ASN[RDA]). The ASN(RDA) is organized into many program executive offices (PEOs) and has direct-reporting program managers (DRPMs) responsible for the acquisition of individual systems and collections of such systems. PEOs playing a central role in naval C4ISR architecture development include the PEO for Command, Control, Communications, Computers, Intelligence, and Space (PEO[C4I&S]) and the PEO(IWS). The full complement of naval PEOs within the major program acquisition chain is shown in Figure 3.3(a). The Chief Engineer (CHENG) shown in this figure is considered to be on an equal level with a PEO, but the CHENG is without a programmatic portfolio. (The role and responsibilities of the CHENG are discussed later in this chapter.) The naval systems commands (SYSCOMs) are also part of this structure, but they manage programs that fall outside the PEO/DRPM structure. See Figure 3.3(b).

OCR for page 70
C4ISR for Future Naval Strike Groups tives is not commensurate with either the importance of the capability (as articulated by the Department of the Navy itself) or the degree of difficulty in achieving the necessary, and arguably unprecedented, levels of horizontal integration. It is also understood that even if a commitment were made to establish the function, there are a number of options with key variables: for example, (1) where in the structure such a position might reside (civilian secretariat or Chief of Naval Operations [CNO] staff) and (2) whether the position would be new or a strengthened version of an existing position (e.g., the Research, Development, and Acquisition [RDA] CHENG in the secretariat or the Chief Information Officer [CIO] on the CNO’s staff). Understanding that such considerations, in the end, are appropriately in the hands of the Navy and Marine Corps, the committee simply observes the following: The Chief of Naval Operations (CNO) and the Commandant, Marine Corps (CMC) have responsibility for requirements development and resourcing. Placing this responsibility on the CNO/CMC staff puts the CHENG in the most effective place to ensure that architectural direction is supported by POR requirements and program-sponsor resource allocations. Considerations both of emphasizing operational mission support and of compatibility with the Goldwater-Nichols acquisition structure favor positioning the recommended Chief Engineers as reporting directly to their Service chiefs. (However, there is precedent for dual reporting to the civilian secretariat as well.) The necessary CHENG influence, including that needed when he or she is sitting at the acquisition table, would argue for a three- or four-star position or civilian equivalent. Considerations of continuity, of course, become important and influence the relative merits of a uniformed versus a civilian position. The creation of such a position and of the supporting system engineering activity would, as noted above, generate questions about what current organizations and/or charters should be absorbed or consolidated. For instance, would the residual responsibilities of the Department of the Navy CIO justify a separate position if a strong CHENG were established with the requisite horizontal information system responsibilities and authorities? There are clearly a variety of ways to provide the requisite system engineering support to the Chief Engineers as long as certain first principles are obeyed: namely, that the system engineering cadre has a robust, experienced core that is dedicated to its mission and assigned unambiguously to the CHENGs. Regarding relationships to current activities, the committee notes that the SPAWAR FORCEnet CHENG function provides a possible foundation for a key subset of the envisioned system engineering capability and could report directly, along with selected elements of the MCSC, to the Service CHENGs. It is considered crucial to maintain the end-to-end mission and enterprise perspective and to resist the pressure to become immersed in expensive weapons

OCR for page 70
C4ISR for Future Naval Strike Groups and platform issues on a program-by-program basis; mechanisms exist to address these more traditional program issues, their importance and difficulty notwithstanding. In many ways, the recommended mission-focused CHENGs would become the CNO’s and CMC’s counterparts of the ASN(RDA) with respect to the engineering and integration aspects of achieving enterprise objectives. There would be an emphasis on C4ISR capabilities in general and on FORCEnet-enabled NCO objectives in particular. 3.5.3 Operationally Significant Capability Increments Clearly, the challenges associated with transitioning from the current C4ISR system-of-systems to the NCO vision are substantial. They entail dealing with either upgrades to or planned phaseout of legacy systems. They include accounting for the interdependencies among developmental systems as they come online (e.g., the dependencies of unmanned aerial vehicle [UAV] sensor platforms on TSAT capabilities for exfiltrating collected information). Addressing these basic transition issues is viewed here as part of the broader system engineering process discussed above. The resolution of such issues is part of the march toward the longer-term NCO capability. Additionally, there is a dimension of transition that the committee views as warranting particular and special attention: the time-phased synchronization of individual program deliveries to provide a continuing series of operationally significant, cross-program mission capability packages. This coordination requires the alignment of programs not only with architectural guidance but with each other, in time, to deliver coherent sets of capabilities to users, while supportive capability deliveries from non-naval programs also need to be factored in. It includes what could be viewed as forward spirals, accelerating the arrival of future capability by focusing on mission-driven capability increments along the path to the longer-term vision. The committee was informed of positive initiatives along these lines. A presentation by the PEO(C4I&S) articulated a strategy of incremental, synchronized deliveries across programs in the form of a roadmap (see Figure 3.4).15 Funding and delivery milestone adjustments across multiple programs were indicated. As another example, an initiative to enhance machine-to-machine targeting time lines by simply introducing Extensible Mark-up Language (XML)-coded flows of selected targeting information was described in the Sea Trial presenta- 15   Andrew Cox, Executive Director, Program Executive Office for Command, Control, Communications, Computer, and Space, “Information Brief to the Naval Studies Board,” presentation to the committee, September 21, 2004, Slide #8.

OCR for page 70
C4ISR for Future Naval Strike Groups FIGURE 3.4 Network-centric, warfare-ready improvement opportunities. NOTE: DSCS, Defense Satellite Communications System; SLEP, Service Life Extension Program; WGS, Wideband Gapfiller System; AEHF, Advanced Extremely High Frequency; MUOS, Mobile User Objective System; TSAT, Transformational Satellite; IPv6, Internet Protocol, version 6; IP, Internet Protocol; GIG-BE, Global Information Grid-Bandwidth Expansion; HAIPE, High Assurance Internet Protocol Encryption; TC QoS, telecommunications quality of service; NAF, Navy Atlantic Fleet; PCF, Pacific Fleet; TC, telecommunications; JTRS WNW, Joint Tactical Radio System Wideband Network Wavef Services/Joint Command and Control. SOURCE: Andrew Cox, Executive Director, Program Executive Office for Command, Control, Communications, Computer, and Space, “Information Brief to the Naval Studies Board,” presentation to the committee, September 21, 2004, Slide #8.

OCR for page 70
C4ISR for Future Naval Strike Groups tion of the Navy Warfare Development Command (NWDC).16 The identification of such opportunities to “accelerate the future” demands close coupling with users (e.g., a systematic program targeted against the fleets’ “Top 10” list of C4ISR issues). It appears, then, that a strategy of synchronizing and correlating individual program deliveries to provide operationally significant capability increments is becoming part of the C4ISR/FORCEnet evolutionary process. However, there was little evidence of an integrated cross-naval process that (1) defines mission-capability packages which cut across multiple PEO and SYSCOM domains, and (2) explicitly addresses the fleets’ “Top 10” C4ISR issues. These apparent gaps are neither unique to the Navy and Marine Corps nor easy to address. Some simply have to be addressed, perhaps with higher priority, within the framework of current organizational efforts and initiatives. However, the committee’s view is that more near-term capability packages could be delivered if there were a horizontal, crosscutting activity dedicated to this purpose. It would seem appropriate that such an activity be under the cognizance of NETWARCOM, perhaps as an extension of existing charters and efforts. Coupling to and support from the broader system engineering effort discussed above would be important. 3.5.4 Summary of Architectural and Implementation Findings and Recommendations The findings and recommendations of this chapter are presented below. Finding: A C4ISR architecture for future naval strike groups should exploit the communications and information-management capabilities of the DOD’s Global Information Grid (GIG), employ command-and-control (C2) systems that operate as one with C2 systems of other Services, access ISR capabilities provided by national and joint systems, provide the ability to establish interoperability rapidly with coalition and other U.S. government agency assets, and provide for specific C4ISR needs associated with the Naval Services’ missions and platforms. In the committee’s view, the DOD’s GIG concept is the appropriate vision for the future, and the Navy and Marine Corps, together with their sister Services, have started down the path to implementing it. Much remains to be done with 16   Wayne Perras, Deputy Commander/Technical Director, Navy Warfare Development Command, “Achieving Dynamic C2 Through Sea Trial,” presentation to the committee, September 22, 2004.

OCR for page 70
C4ISR for Future Naval Strike Groups respect to ensuring QoS for critical missions, information assurance, and network management.17 Requirements with respect to key aspects of the C4ISR architecture for naval strike groups in major combat operations are driven by the necessities of operating jointly and in the littorals. Recommendation: The CNO, CMC, and ASN(RDA) should adopt a top-level conceptual representation of the C4ISR architecture for future naval strike groups. For a top-level conceptual representation of the C4ISR architecture for future naval strike groups, the committee offers the views presented in Figures 3.1 and 3.5. Figure 3.1 depicts the future naval C4ISR architecture as an Internet-like core with various information sources and user enclaves connected to it. The Internet-like core builds on widely implemented Internet standards and includes a number of additional technologies and capabilities needed to meet the unique requirements of DOD applications. A variety of enabling network services are provided, by and through the network, to the users. There is a considerable distance between this vision and today’s capabilities and paradigms, and the Naval Services need to participate in reducing the various risks associated with the transition. Figure 3.5 indicates that the Navy’s C2 systems should be built, in accord with the Navy’s current plan, using a service-oriented architecture (SOA) approach. The SOA approach has been developed in the commercial sector for enterprise software systems. To promote reuse and flexibility, it separates out and provides externally callable interfaces to the various components—the data, application logic, user presentation, and orchestration (used to achieve a given work flow) components—of applications; that is, the SOA approach restructures them as services. By providing a discovery service18 and other core enterprise services in addition to application services, it facilitates the use of externally developed services located at other GIG nodes, a key attribute of network-centric operations. As is acknowledged in Figure 3.5, however, certain legacy and special-purposes systems, as well as those with limited bandwidth connectivity to the GIG, will be connected to the GIG via gateways. The ISR architecture should have platforms and sensors networked and layered and operated as part of the Naval Services’ major missions (e.g., Strike, 17   The section on “Implementation Imperatives and Major Recommendations” in the Executive Summary of FORCEnet Implementation Strategy includes as a guiding principle to “exploit GIG capabilities while preparing to fill GIG gaps and determining the limits of network centricity.” See National Research Council, 2005, FORCEnet Implementation Strategy, The National Academies Press, Washington, D.C., p. 2. 18   A discovery service is a system for registering other services so that they can be found and used in new applications.

OCR for page 70
C4ISR for Future Naval Strike Groups FIGURE 3.5 Planned architecture of Navy command-and-control systems, using service-oriented approach where applicable. NOTE: Services are shown in italic type. Ellipsis denotes nodes to come.

OCR for page 70
C4ISR for Future Naval Strike Groups Theater Air and Missile Defense, and Undersea Warfare). Each major mission will benefit from at least two of the multiple layers (space, airborne, surface, and subsurface). Networked sensors will enhance detection and tracking by taking advantage of multiple perspectives and multiple frequencies. Sensors should be networked in major missions, not within layers. Each major mission should control certain platforms and sensors in each layer and operate a local-area network that tasks sensors and collects and fuses sensor data to create a tactical picture that meets the commander’s needs for that mission area. See also the second recommendation in Section 7.6 in Chapter 7 of this report regarding improving technology and exploitation of ISR systems. Each local-area network should be tied to the GIG and thereby provide collected sensor data to other mission areas. Although there is ongoing activity to develop a DOD-compliant network-centric architecture for C4ISR, evidence is only now emerging that the fundamental principles of achieving network-centric capabilities—as articulated in Section 3.2 above—are being adequately articulated and internalized. Additionally, there are multiple sources of architectural guidance being proposed and developed within the Department of the Navy, some of which are ambiguous in their scope and authority and/or are potentially inconsistent. Steps are being taken to address these issues, but there still appear to be organizational stovepipes to be overcome, as well as a need for selective clarification of the organizational scope and responsibility. Similar issues exist relative to applying architectural guidance from external communities with which the naval architectures must interface—especially the Office of the Secretary of Defense’s Global Information Grid (GIG) architecture, standards, and first-level network-centric principles. Beyond further reconciliation and consolidation of current guidance, there is the yet-unfulfilled need to go beyond the core enabling infrastructure and to develop tangible, mission-driven guidance pertaining to platforms and information and applications. The committee believes that a consistent and extended articulation and application of fundamental principles and information-handling paradigms will considerably assist the Department of the Navy in achieving the anticipated improvement in performance provided by network-centric operations (NCO). Furthermore, the Department of the Navy needs to undertake evolving and/or tailoring community standards and guidance for naval missions. Current and emerging efforts provide a foundation, but there is a need to further strengthen cross-organizational mechanisms and resourcing. Finding: Despite important steps taken over the past few years and additional steps beginning to be taken as of this writing, the Department of the Navy’s mechanisms for the system engineering of enterprise-wide network-centric mission capability—and for guiding and directing programs toward these outcomes—need to be further strengthened in terms of scope, content, management authorities, and resources.

OCR for page 70
C4ISR for Future Naval Strike Groups System engineering efforts focused on enabling information infrastructures need to be more robust and to be complemented by mission-driven, end-to-end engineering and integration of the C4ISR enterprise. Current management mechanisms, while being strengthened, are not viewed as commensurate with either the importance or the degree of difficulty of successfully addressing the largely unprecedented “horizontal integration” challenges of the naval C4ISR enterprise. In particular, neither the ASN(RDA) Chief Engineer, as currently defined, nor the SPAWAR FORCEnet Chief Engineer has adequate authority and resources to meet the need. This situation may well result in the implementation of capabilities that neither achieve the full promise of network-centric operations nor entirely satisfy operational mission requirements in a naval or joint context. It may also result in critical vulnerabilities that U.S. adversaries may exploit. As noted, this finding is not intended to dismiss the importance of steps that already have been taken or are being taken by the Naval Services. Ongoing and planned FORCEnet initiatives will bring about progress toward NCO. Further, and also as noted above, the need to strengthen and modify current system engineering and acquisition mechanisms to achieve cross-program, horizontal objectives is surely not unique to the Department of the Navy. This struggle is occasioned by the inherently vertical nature of legal acquisition and funding mechanisms in evidence throughout the DOD. For instance, the Office of the Secretary of Defense for Acquisition, Technology, and Logistics (OSD[AT&L]), the Office of the Secretary of Defense for Networks and Information Integration (OSD[NII]), and the Joint Staff (J6) are co-leading, as of this writing, a fundamental review of the way ahead in technical and acquisition areas with respect to the fielding of the NCO environment (the integration of the core programs). Options include the creation of a joint program executive officer whose portfolio would encompass the requisite programs, or even a joint agency of some kind. The committee’s perspective, then, is captured in its phrasing from the paragraph before last: “Current management mechanisms … are not viewed as commensurate with either the importance or degree of difficulty….” That perspective is the motivator for the recommendation that follows. Recommendation: The CNO, in consultation with the ASN(RDA), should establish a senior Navy Chief Engineer with the responsibility, authority, accountability, and resources for achieving mission objectives through the integration of naval and non-naval programs and capabilities. The CMC, in consultation with ASN(RDA), should establish a Marine Corps counterpart to the Navy Chief Engineer. The Navy Chief Engineer and his or her Marine Corps counterpart should be supported by a robust, enterprise-wide mission systems engineering and experimentation activity to guide and shape major component programs toward the objective of achieving full network-centric C4ISR system-of-systems capability.

OCR for page 70
C4ISR for Future Naval Strike Groups The CNO, CMC, and ASN(RDA) should do the following: Invest the Navy Chief Engineer and his or her Marine Corps counterpart with sufficient authority to (1) issue to naval program managers (including those responsible for weapons platforms) authoritative guidance to achieve network-centric C4ISR; (2) influence operational and technical requirements and resources across naval capabilities, including programs of record and system components, to ensure end-to-end network-centric capability; (3) lead the enterprise-wide systems engineering capability; (4) participate in senior acquisition forums; and (5) establish acceptance criteria for systems and equipment, including their certification for safe and effective use prior to deployment. The guiding principles for a naval network-centric architecture must be consistent with those of the Assistant Secretary of Defense for Networks and Information Integration (ASD[NII]), and establish mechanisms and processes to examine the alignment of systems and programs toward these principles and address divergence, demanding a compelling burden-of-proof case for any deviation. Provide sufficient engineering resources and mechanisms, including levers (e.g., control of milestone-related incremental project-funding authorization, project milestone completion-approval authority) to drive cross-program integration, to enable the Navy Chief Engineer and his or her Marine Corps counterpart to work with PEOs to engineer naval systems-of-systems. The Navy Chief Engineer and his or her Marine Corps counterpart must be informed regarding matters involving technical, cost, schedule, and risk issues as a basis for their guidance and influence—thus the need for a robust, dedicated system engineering activity building on related ongoing activities. Augment engineering, modeling, testing, and integration strategies, tools, and facilities to ensure system-of-systems design integrity and to place realistic bounds on end-to-end performance. This recommendation, simply stated, is designed to fill the gaps related to the phrasing “not viewed as commensurate.” It is aggressive in management terms, as justified by the “importance” and “degree of difficulty” attached to the enterprise-wide challenges associated with driving C4ISR and selected weapons platform systems toward a network-centric future. Finding: While the Navy has important initiatives under way with respect to transition planning for C4ISR architectures, more needs to be done. In particular, the Department of the Navy’s current and planned processes and approaches for transitioning from legacy to modern C2 systems do not adequately deal with the complexity and dynamics of emerging technologies and requirements. An acquisition policy and process are emerging, as of this writing, which call for assessment of the network-centric potential of both legacy and developing

OCR for page 70
C4ISR for Future Naval Strike Groups systems and the modification of program investments and direction accordingly. And FORCEnet roadmap efforts are under way. However, there is little evidence that these efforts provide for coherent, incremental deliveries of capability that cut across multiple PEO and systems command programs. Perhaps most importantly, the committee could not identify an effort focused on seizing nearer-term opportunities to field discrete, coherent forward spirals of network-centric capabilities at identified and scheduled milestones (i.e., a progression of mission capability packages). This latter aspect of transition deserves special attention. Giving special attention to this aspect of transition would help to address the paradox generated by competing objectives—systematically engineering the delivery of ensured, integrated NCO capability over a relatively long time period (e.g., 8 to 10 years) and responsively delivering capabilities more quickly to support compelling user needs. Real possibilities for providing early capabilities exist. They are enabled both by the delivery of substantial increments of GIG core capability in the fiscal year (FY) 2005 and FY 2006 time period, as shown in Figure 3.2, and by related naval program milestones. Examples include the Navy exploitation of NGA imagery available over the GIG-BE, as discussed in Section 3.2, as well as XML-enabled machine-to-machine information flows, as noted previously in the context of Sea Trial results. Further, opportunities to “accelerate the future” were identified in the PEO(C4I&S) presentation to the committee.19 Again, these opportunities should be seized. Recommendation: The Navy Chief Engineer and his or her Marine Corps counterpart should initiate a transition-planning and -analysis activity for the near, mid-, and long term, with priority for development placed on systems that enable significant and measurable improvements to key mission threads.20 In particular, the PEO(C4I&S) should focus its transition efforts in selected mission areas in order to achieve the critical mass necessary to manage transition complexity and to make full use of emerging technologies and requirements. Doing so would also position the Navy to satisfy its requirements in a way that meets joint Service capability needs. The near-term planning and analysis activity conducted by the Navy Chief Engineer and his or her Marine Corps counterpart should accelerate the network- 19   Andrew Cox, Executive Director, Program Executive Office for C4I and Space, “Information Brief to the Naval Studies Board,” presentation to the committee, September 21, 2004. 20   The committee could find no formal definition of “mission thread.” A working definition is given in Section 2.2.2: “A mission thread is a sequence of activities and events beginning with an opportunity to detect a threat or element that ought to be attacked and ending with a commander’s assessment of damage after an attack.”

OCR for page 70
C4ISR for Future Naval Strike Groups centric future by aligning and synchronizing C4ISR components into discrete, coherent segments of the naval network-centric architecture that enable significant naval mission capability increments and should operate within the joint context. That near-term planning and analysis activity should prioritize the capability increments to be transitioned for network-centric operations and identify the DOD communities of interest (COIs) most instrumental to the success of the transition. As noted above, the near-term-focused activity should identify forward spirals. The mid- and long-term activities should include processes that both foster the development of network-centric components and examine whether legacy components should remain, be divested, or be enhanced for inclusion. The intended result is the creation of mission capability packages that represent progress along the longer-term network-centric operations vector while responding to near-term operational needs. The efforts of the PEO(C4I&S) should include the following: Create teams with the required expertise for each COI and task them to define COI services supplementing Network Centric Enterprise Services and COI data requirements as the basis for the needed metadata schemas. Design and develop those COI services, using a spiral development and acquisition program to achieve executable architectures. Build a spiral acquisition program for these COI services using modeling and simulation akin to the Navy Distributed Engineering Plant and Sea Trial experimentation to help validate the iterative evolution of these services. Interaction with red teams (adversary) in experimentation would add in making this evolution robust.21 Take a lead in joint developments, for example, Joint Command and Control (JC2), as part of this spiral acquisition process; in this way, bring particular naval expertise to bear in supporting the joint community and ensure that naval needs are met in joint developments. One example of naval expertise is that of tracking management development for the JC2 Common Operational Picture. 21   See National Research Council, 2004, The Role of Experimentation in Building Future Naval Forces, The National Academies Press, Washington, D.C.