Architecting and Building the Naval C4ISR System
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.
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
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
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
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.
Until TSAT is deployed, Navy ships will connect to the GIG using the satellite communications (SATCOM) systems discussed in Chapter 6, “Communications.”
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
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
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.
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-
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.
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).
The Marine Corps Systems Command (MCSC) is also part of this ASN(RDA) structure,6 managing acquisition for the Marine Corps and reporting directly to the ASN(RDA). Within the MCSC organization, there is a Marine Air-Ground Task Force (MAGTF) C4ISR product group consisting of several program managers.
The PEO(C4I&S) oversees 118 command, control, communications, computers, and intelligence (C4I) programs and products and is charged with the
mission of acquiring, integrating, delivering, and supporting interoperable C4I and space capabilities for the fleet, joint, and coalition warfighters. As such, the organization is positioning itself to implement the C4I portion of FORCEnet to enable ships, submarines, aircraft, and shore nodes to become network-centric.
In a recent analysis, the PEO(C4I&S) determined that the programs that it oversees were not optimally structured to deliver a maximum, integrated capability in a timely manner. Only about 30 percent of the fleet was scheduled to have even a minimal capability for network-centric warfare (NCW) by 2009.7 To address this situation, the PEO(C4I&S) has reorganized to focus on capabilities rather than products.
The organization has undertaken a major cross-Service effort between the Navy (Reusable Application Integration and Development Standards [RAPIDS]) and the Air Force (Command and Control Enterprise Reference Architecture [C2ERA]). The purpose of this endeavor is to provide a technical architecture, implementation guidance, technical criteria, and reusable software components to create a common technical foundation between the Navy and Air Force C4I to facilitate the design and development of information systems for network-centric warfare. The result of this undertaking is called the Network-Centric Enterprise Solution for Interoperability (NESI). Further, it appears that the Army is also becoming engaged in the NESI process and product.
There are many positive aspects of this endeavor. It is an effort to realize solutions that are vendor-neutral and program-, platform-, and Service-agnostic. It uses a service-oriented architectural approach, complementary to the GIG/Net-Centric Enterprise Services (NCES) infrastructure, targeted at reducing dependencies by encapsulating implementation behind service interfaces. It incorporates use of the ASD(NII) checklist for network-centricity. Although it is still struggling with challenges to complete its guidance, NESI is an example of a worthwhile, multilateral Service endeavor, initiated by the Navy, to converge guidance and realize joint interoperability for network-centric operations.
The PEO(IWS) oversees the design, construction, and development of ship combat systems and has responsibility for 95 programs and projects. In 2002, the PEO(IWS) initiated efforts to transition from a platform-centered approach to an integrated, cross-Navy approach for combat and warfare systems capabilities. The ASN(RDA) has charged the PEO(IWS) with the development of an open architecture (OA)8 to facilitate the evolution of computing environments through-
out the Navy. This integrated approach was motivated by commonality and reuse within the weapons platform community. The OA approach envisions the establishment of a Navy-wide technical architecture based on international standards and the development of a Navy-wide functional architecture with standardization of components and critical interfaces.
This strategy has provided a useful layering structure defined at a technical level rather than a system architecture level. The approach was developed through a Naval Sea Systems Command (NAVSEA) initiative and incorporates the ideas of invariant boundaries and functional partitioning. The recent Naval Studies Board report entitled FORCEnet Implementation Strategy recommended these OA features as particularly relevant for FORCEnet because they facilitate the engineering of complex systems and their evolution over time.9
While OA has been described as being applicable to the central elements of FORCEnet as well as to computing environments within platforms, it is not clear that the applicability, relationship, or the attendant compliance responsibilities are well understood or accepted within the Navy. Nor does it appear to be fully understood how they relate to other guidance, such as standards designated by the Space and Naval Warfare Systems Command (SPAWAR). As part of the FORCEnet architectural efforts, an open architecture convergence effort is under way to relate the functional architectures of the FORCEnet architecture with the OA computing environment and to articulate compliance criteria so as to develop a future integrated-architecture document.
While the committee believes that the efforts of the PEO(C4I&S) and PEO(IWS) are moving in the right direction, there remain challenges in maintaining consistent technical guidance and consistent interpretation across the broader enterprise (and stovepipes, i.e., individual entities) so as to realize horizontal integration. Within the ASN(RDA) organization, the CHENG might potentially provide the necessary crosscutting guidance and direction.
The CHENG serves as the senior technical authority10 for architecture and integration and interoperability, with duties that include capturing and promulgating system and technical architectures, standards, protocols, and processes, bridging Navy and Marine Corps as well as OSD and joint organizations. While this mission covers all warfare areas, including C4I, combat systems, and weapons systems and is intended to ensure that the Department of the Navy delivers integrated enterprise capabilities, the organization is lightly resourced and has limited authority. As a telling example, the Marine Corps has one position to support the CHENG, not filled at the time of this writing.
The committee noted that the CHENG, although trying to increase influence, does not have the authority and resources necessary to enforce architectural guidance, such as through milestone decisions or budgetary authority, nor to manage the development of systems to achieve a systems-of-systems capability (e.g., Time Critical Strike). The CHENG is not a centralized authority that is first among equals, but appears to rely on early and timely coordination, and on negotiation rather than on more effective processes to deal with competing directions and proposed deviations.
The CHENG is currently focused on standards setting at a high level, with efforts directed at resolving inconsistencies across programs. An overarching strategy is to use open architectures and standards-based solutions such as IPv6, along with other DOD-wide information infrastructure capabilities. Engineering the interfaces and functional interactions across the boundaries of the various systems, capabilities, and programs (and across PEOs) is very problematic—the topic is discussed more in depth later in this chapter—and an activity that is well beyond the resources and authority of the office as currently structured.
3.4.2 FORCEnet Architectural Efforts
The Department of the Navy is aware of the challenges associated with NCO and has taken a number of steps—some without clear analogs in the other Services—to place particular emphasis on its achievement. These steps include the following:
The creation of the Naval Network Warfare Command (NETWARCOM), with its user-/fleet-driven charter and responsibilities for moving FORCEnet forward.
The assignment of FORCEnet system and technically oriented responsibilities to SPAWAR, including the designation of SPAWAR as the FORCEnet Chief Engineer and the assignment to SPAWAR of responsibility for assessing programs vis-à-vis FORCEnet objectives. The assignment of FORCEnet technical authority within the virtual SYSCOM construct provides at least formalized influencing mechanisms for the FORCEnet CHENG when applying guidance and exercising technical direction across naval development and acquisition organizations and their programs.
The establishment of a variety of cross-program/cross-organization mechanisms in recognition of the fact that such boundaries are necessarily crossed to achieve the targeted NCO capabilities. These include not only the virtual SYSCOM mechanism, but—notably—the FORCEnet Executive Committee led and chaired by the ASN(RDA) and including the full range of naval stakeholders, along with representatives from the joint community. The committee observes that the ASN(RDA) has assumed a proactive role regarding
FORCEnet implementation, including the difficult task of trying to free up funding for FORCEnet by capping resource expenditures in other areas.
Within the framework of the FORCEnet Executive Committee, the ASN(RDA)’s tasking of the development of a new acquisition policy devoted to the achievement of NCO/FORCEnet objectives within the acquisition community.
Steps to harmonize Navy-wide technical guidance mechanisms, including the activities of the ASN(RDA) CHENG, the open architecture activity of the PEO(IWS), and the FORCEnet-focused technical architecture and standards activities (and products) of SPAWAR.
The use of experimentation, such as in Sea Trial, to explore the operational payoff from NCO and its ramifications with respect to doctrine, organization, training, materiel, leadership and education, personnel, and facilities (DOTMLPF).
The FORCEnet architectural efforts are developing both operational views and system and technical views, with responsibility assigned to NETWARCOM and the SPAWAR FORCEnet CHENG, respectively. NETWARCOM is responsible for the development of the functional concept and operational views of the FORCEnet architecture, while the Marine Corps Combat Development Command (MCCDC) provides operational focus for the Corps. SPAWAR is developing both system and technical architectures for FORCEnet in conjunction with the MCSC, and the FORCEnet Chief Engineer is in SPAWAR. Presentations to the committee indicated an almost exclusive emphasis on the FORCEnet enabling information infrastructure, with a seemingly protracted schedule for addressing the crucial topic of mission threads.
The FORCEnet architectural efforts are employing the standard DOD Architectural Framework (DoDAF) with its operational and its systems and technical views. NETWARCOM describes the operational views as having multiple purposes, including the creation of event-trace diagrams needed as inputs for the Office of the Chief of Naval Operations’s (OPNAV’s) Program Objective Memorandum (POM)-08 campaign analysis. NETWARCOM intends to produce an apparently comprehensive set of event-trace diagrams as the last of a sizable six-step process that includes the development of such things as information exchange requirements (IERs) for a large number of different naval missions. Given that the models that OPNAV employs in the POM-08 campaign analysis are high-level ones, the committee believes that it would be a better path for NETWARCOM to come to understand exactly what the campaign analysis models require (what key missions should be considered, what form the input should have) and produce only that, with as little effort as possible expended on precursor or peripheral items.
Turning to the SPAWAR effort, the committee understands that an architecture-and-standards product has been developed and that an initiative to assemble
and assess a FORCEnet Implementation Baseline is under way. At this writing, the committee is unsure of how the FORCEnet Implementation Baseline will be used, but the cognizant organizations should look hard at that question and economize the effort to produce only what is clearly needed. The effort might include a focusing down from more than 400 potentially relevant programs to a short list of critical, NCO-enabling naval programs—analogous to the identification by the Office of the Secretary of Defense for Networks and Information Integration (OASD[NII]) of seven enabling infrastructure programs for special attention (see Figure 3.2). These would be subjected to in-depth, engineering-level assessments of their alignment with NCO objectives. This positive outcome is strongly encouraged. Further, as the committee understands it, an ASN(RDA)-driven process is emerging that will place relevant FORCEnet programs into “bins” defined by their relative ability to support NCO objectives. Programmatic purposes and mechanisms are discussed in the following section.
The committee questions whether the considerable effort going into these architectural processes will provide commensurate value. IERs model the current information-handling paradigm rather than the network-centric one.
As elaborated below, progress has been and is being made in the form of both SPAWAR FORCEnet CHENG and PEO products (consolidated program manager [PM] guidance based on the Net-Centric Checklist, NESI, and so on). However, the committee judges that there is a distance to go in both reconciling and strengthening these sources of guidance.
The committee shares the concerns of a predecessor Naval Studies Board committee that addressed itself specifically to a review of the FORCEnet implementation strategy. That NSB study delineated three components of FORCEnet:
The doctrine, tactics, techniques, and procedures for conducting network-centric operations, and warriors trained in those concepts;
Materiel developed and acquired in accordance with an architectural framework that enables these operations; and
An information infrastructure that integrates the warriors and materiel in the conduct of these operations.11
NETWARCOM complements its “architectural framework” definition of FORCEnet with an “operational definition,” that is, “the systems and processes for providing networked naval command and control.”12 There is some concern
National Research Council. 2005. FORCEnet Implementation Strategy, The National Academies Press, Washington, D.C., p. 3.
See 2004, CHIPS – The Department of the Navy Information Technology Magazine, “Interview with Vice Admiral James D. McArthur, Jr., Commander, Naval Network Warfare Command,” Fall. Available at <chips.navy.mil/archives/04_fall/web_pages/admiral_mcarthur.htm>. Accessed January 26, 2006.
that NETWARCOM’s definition is too narrow to include all three components of FORCEnet as identified in the NSB study, but the limited view does have the useful effect of focusing NETWARCOM and SPAWAR on the development of capabilities for which they can reasonably be held responsible, the FORCEnet Information Infrastructure. The disadvantage is that the mission kill chain is not fully addressed. For example, under the network-centric paradigm, targeting latencies are strongly influenced by end-to-end performance of the common infrastructure.
The current focus on enabling the information infrastructure is appropriate in that these capabilities provide the foundation of the C4ISR architecture. However, there is the question of balance among the various architectural efforts. The current focus leaves unresolved the question of how the Department of the Navy will perform system-of-systems engineering of its end-to-end mission capabilities and meet the high performance needs of a C4ISR architecture. Additionally, the assumptions underlying FORCEnet are that the core network and its services will be provided by the DOD, by and large, in its development of the GIG. This requires a clear strategy for complying with those interfaces and synchronizing with those capabilities, yet how this compliance and synchronization will be actually realized within the Department of the Navy is not clear, given the present limited authorities and resources of both the ASN(RDA) CHENG and the FORCEnet CHENG in SPAWAR. It will require systems engineering processes appropriate to the scale and complexity of the task, not merely the reviews of an integration board, albeit one supported by technical compliance processes. This matter is addressed in Section 3.5.
3.5 FINDINGS AND RECOMMENDATIONS
The fielding of a naval C4ISR capability requires, as a foundation, the successful execution of individual programs. Relative to the execution of individual programs, there is a body of accepted systems engineering and acquisition processes and methodologies (even though they are not always put into practice). There is the acquisition management structure defined by Goldwater-Nichols,13 intended to ensure adequate accountability and authority with respect to individual programs of record (PORs). However, achieving the successful delivery of a naval C4ISR enterprise capability that will inherently cut across multiple programs and systems and that will be developed and acquired by different organizations poses a number of technical and management challenges. The committee’s view is that these challenges require the following:
A translation of broad architectural guidance to more-definitive engineering guidance when—and only when—more-definitive guidance is needed to ensure system-of-systems enterprise outcomes. End-to-end quality of service (QoS) and selected aspects of IA (e.g., black core trade-offs) are examples of such enterprise outcomes.
Technical and programmatic mechanisms for ensuring program alignment with architectural guidance, including (1) mechanisms for assessing requested waivers and/or deviations and for granting approvals on a compelling-case-only basis and (2) processes for iterating the broad architectural guidance itself, as required, on the basis of technical considerations (e.g., performance impacts of a selected protocol) or programmatic experience (e.g., limitations on the pace of POR adjustment).
A continuous process of reassessing the balance between operational capabilities and technical and programmatic options, including a consideration of cost and schedule risk.
A robust set of simulation/analysis and test/exercise activities both to verify end-to-end design integrity and to establish realistic bounds (and therefore expectations) on end-to-end performance.
The development of an agreed-to community process for executing the equivalent of developmental and operational testing and evaluation (T&E), understanding that the traditional program-by-program process in place today requires modification when dealing with enterprise-wide, horizontal capabilities.
The maximum practical flexibility to make cross-program funding and milestone adjustments within the requisite C4ISR program portfolio, understanding that this portfolio cuts across PEO and SYSCOM areas of responsibility.
These processes and mechanisms go well beyond standards-based interoperability, control of interfaces, and the attendant compliance—all of which is necessary but not sufficient.
3.5.1 Architectural Guidance
The committee has emphasized the need for architectural imperatives for network-centricity that are accepted across all activities of the Naval Services and are implemented in a consistent fashion. The Department of the Navy should not only take ownership of these principles but also should lead the evolution of guidelines and standards that are most important to its problems. It was observed earlier that, as of this writing, there does not appear to be sufficient Department of the Navy ownership of such principles to change how programs are progressing or to move resources from programs that will never fit into this new environment of network-centricity. It is noted also, however, that activities and mechanisms are emerging that offer promise in this regard (e.g., the new FORCEnet acquisition policy).
The committee believes that there is a need to align, reconcile, and consolidate the technical guidance from the various sources including the DOD-wide and Joint Enterprises, the ASD(NII)’s Joint Technical Architecture and NCES, naval C4ISR analyses, FORCEnet architecture and standards products, and other worthwhile efforts under way, such as the PEO work on open architectures and NESI. The architectural guidance must be consistent, and sufficiently actionable to support meaningful guidance to and interactions with program managers, as well as informed decisions on requests for deviations and waivers.
Regarding the need for a single, consistent source of guidance for program managers, the committee understands that the SPAWAR FORCEnet CHENG is developing such a product.
More fundamentally, the committee has some concerns about the scope or focus and content of the guidance developed to date—concerns that would not be addressed by reconciliation and consolidation. On the positive side, guidance in sources ranging from NETWARCOM’s FORCEnet Compliance Criteria (FCC), to the SPAWAR FORCEnet CHENG’s architecture and standards, to the PEO(C4I&S)’s NESI product have converged substantially with the ASD(NII)’s Net-Centric Checklist and, therefore, are beginning to reflect the fundamental design principles and information-handling paradigms outlined in Sections 3.2 and 3.3 above. However:
With the exception of standards for interoperability and for commonality of computing platforms, the subject of sensor and weapons platform capabilities required to achieve NCO is not well developed; generally this information is to be manifested in combat direction systems and their interfaces with other organic systems (e.g., sensors). For instance, how does the principle that every platform is a sensor translate into architectural guidance to platform designers (e.g., onboard storage and playback to support the posting of situational awareness information from a combat aircraft returning from a mission)?
Even given this further enrichment, the evolving guidance is focused almost exclusively on the important topic of the enabling information infrastructure but with limited attention on the fundamental principles and paradigms that will allow the exploitation of this infrastructure. What specific guidance regarding data handling and fusion would obviate the problems often experienced today with the common operational picture?
It should be noted that such gaps in guidance are not unique to the Naval Services. All Services—and the DOD and joint community overall—are struggling not only with guiding and building the core enabling infrastructure, but with extending it to the tactical edge and pressing mission-driven information flows and applications to exploit the infrastructure in concert with evolving concepts of operations (CONOPS).
3.5.2 System Engineering and Naval Service Chief Engineers
As noted above, consistent and sound architectural guidance is necessary but not sufficient for the development of a network-centric naval C4ISR capability. Architectural guidance needs to be complemented by an influential and adequately resourced system engineering activity, which should include the following individual activities:
Substantively reviewing programs from the viewpoint of their alignment with the FORCEnet/NCO vision;
Evaluating various requests for waivers and deviations on their merits;
Conducting a broad range of system-level trade-offs, including consideration of cost and schedule implications;
Translating architectural guidance and principles into next-level engineering imperatives when required;
Conducting both analytic simulations and hardware/software-in-the-loop integration tests to validate end-to-end system integrity and establish end-to-end performance boundaries (e.g., using the Joint Distributed Engineering Plant [JDEP] and the Navy Distributed Engineering Plant [NDEP]);14 and
Participating with the development and operational testing communities in the new world of capabilities-based acquisition.
Beyond this list of system engineering activities, there are critically important attributes of the process that go beyond the technical work per se. These include the following:
Adopting explicit, mission-driven outcomes to inform the system engineering trade-offs and the resulting programmatic guidance, going beyond the engineering of the enabling information infrastructure and including the engineering and integration of end-to-end mission threads (e.g., time-critical strike) and multimission capabilities (e.g., situational awareness).
Identifying and focusing on a short list of the most critical NCO-relevant programs from the viewpoint of alignment. This effort would be analogous to the OSD(NII)’s focus on the seven core GIG programs (TSAT, JTRS, GIG-BE, NCES, IA and High Assurance Internet Protocol Encryption [HAIPE], Teleport, Joint Network Management System [JNMS]). The list could be the result of the SPAWAR FORCEnet Implementation Baseline assessment.
Maturing a process to assess legacy as well as developmental programs
from the viewpoint of their potential contribution to NCO capability, influencing investment decisions as well as program direction.
Ensuring collaborative, technically based engagement with the cognizant key program managers, including those outside the Navy, for programs on which the Navy is critically dependent (e.g., TSAT).
Addressing concerns about enabling the information infrastructure by (1) attacking technical issues by layer whenever possible (e.g., by networking, services, data, and application layers) and (2) identifying and addressing critical cross-layer issues involving QoS, network and system management, and information assurance as particularly crucial.
Placing emphasis on those mission-driven capabilities that are most stressing. For example, the notion of “power to the edge” becomes challenging when supporting potentially disadvantaged users at the tactical edge.
More broadly, striving for a structure in which program alignment requires compliance with only a minimally prescriptive, reasonably short list of rules, ruthlessly enforced but with maximum prerogative on the how versus the what being left in the hands of program managers (loose versus tight integration).
Steps being taken by the Navy and Marine Corps and across the Department of the Navy arguably address the activities and attributes delineated above. Earlier discussion in this chapter noted important steps to strengthen and mature the program assessment and alignment process and to institutionalize such processes and the attendant organizational responsibilities and authorities (e.g., the ASN[RDA]-directed FORCEnet acquisition policy currently undergoing review). However, the current FORCEnet system engineering activities are distributed among multiple participants despite the central role of the SPAWAR FORCEnet CHENG. These dispersed activities are very lightly resourced and not always well coupled. There appear to be tasking and additional duties for selected participants in which the resources are taken “out of hide” or out of those resources existing at the time; this is understandable in the current fiscal climate, but it is not a formula for success. Further, the committee perceives gaps in the breadth and depth of the ongoing system engineering efforts that are driven partially—but not exclusively—by organizational divides and resourcing issues.
For example, with respect to the engineering of the enabling infrastructure and its interfaces, there is appropriate emphasis on attributes such as interoperability and commonality, but not on in-depth engineering and analysis of the short list of topics that are essential for end-to-end performance and, in the end, for operational capability. These attributes include QoS, IA, and JNSM; each should be addressed at the enterprise level. Dealing with QoS demands an approach to decomposing the network into its major pieces (heterogeneous, wide-area and local, and so on); it also requires attention to matters such as the available QoS protocol options for the pieces and their interactions when driving end-to-end user performance. Some of the major pieces are, of course, in the hands of other Service program managers and
constitute the core GIG. Engagement in the ASD(NII)-led end-to-end system engineering activity provides a venue for dealing with these extra naval topics and their impacts (e.g., expected network latency).
In addition to infrastructure issues, there is need to explore and understand the system and/or program implications of supporting naval missions in a network-centric way. For instance, there is the much-studied problem of ensured, unambiguous tracking of threat objects (missile, aircraft) that might be encountered by an expeditionary strike group (ESG) or a carrier strike group (CSG). In addition to taking advantage of the impressive capabilities of the cooperative engagement capability (CEC), the NCO paradigm offers access to potentially useful information from nonorganic sources under the banner of “sensor networking.” However, questions arise such as what latencies would be acceptable, what fusion approaches or algorithms might apply, and whether utility would be found in terms of cueing or actually improved firing solutions. Answers would impact the end-to-end design, perhaps including the performance demands on the network itself and its services.
Similarly, there are NCO-related mission engineering and analysis topics to be addressed pertaining to joint operations. For example, naval forces are envisioned as key participants in a Joint Fires Network under certain scenario conditions (e.g., antiaccess). A variety of target-identification, target-nomination, and target-and-weapon pairing options arise involving other Service capabilities. What are the required information flows to make these options available to the Joint Force Commander in practice? What do these information flows imply regarding naval system interfaces with non-naval platforms and C2 and intelligence facilities? What do they imply regarding program impacts?
More broadly, it is crucial that mission-driven system engineering be performed as an integral part of the front-end requirements-development process as well as during the process of guiding programs of record toward C4ISR enterprise objectives. Although there will always be legacy systems to be accommodated, long-term success demands that systems and programs be “born net-centric” as well as “born joint.”
The recommended system engineering activity is envisioned as a modestly sized, centralized activity. With the objective of coherence as well as resource efficiency, it would absorb and/or consolidate, at least functionally if not organizationally, a number of activities that are ongoing today. Care would be taken, for activities that remain separate, to carefully demark their scope, responsibility, and authority.
To lead the system engineering activity, the committee recommends (see Section 3.5.4) that the Navy establish a senior Navy Chief Engineer position and a Marine Corps counterpart, reporting directly to their respective Service chiefs. It is understood that such a recommendation poses a number of institutional and organizational issues. The committee is motivated, however, by the basic finding that the strength of the mechanisms currently in place to achieve FORCEnet/NCO objec-
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
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-
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
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,
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.
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.
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
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-
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.
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.”
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.