National Academies Press: OpenBook

C4ISR for Future Naval Strike Groups (2006)

Chapter: 4 Command-and-Control Systems

« Previous: 3 Architecting and Building the Naval C4ISR System
Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×

4
Command-and-Control Systems

4.1 INTRODUCTION

The development of a command, control, communications, computers, intelligence, surveillance, and reconnaissance (C4ISR) architecture based on the Internet Protocol, a service-oriented architecture (SOA), and the developing capabilities of the Global Information Grid (GIG), as discussed in the previous chapter, promise to provide important elements of the flexible C4ISR needed for flexibly constituted naval strike groups. This chapter focuses on the command-and-control (C2) portion of C4ISR and on the relationship of Navy research and development programs to the vision of network-centric operations (NCO) outlined in Chapter 3. The status of naval C2 systems development (Section 4.2), including efforts related to establishing a common operational picture (COP) (Section 4.3), is reviewed first. Research efforts within the Navy and the Department of Defense (DOD) addressing C2 systems employing SOAs and related advanced concepts are then surveyed (Section 4.4). Finally, some of the issues associated with the transition from current to future C2 systems are discussed (Section 4.5). Based on this discussion, findings and recommendations are presented (Section 4.6).

4.2 CURRENT COMMAND-AND-CONTROL SYSTEMS AND FUTURE DEVELOPMENTS

The Navy uses tens of systems that can be categorized as C2 systems. The programs for most of these systems are in the Program Executive Office for

Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×

TABLE 4.1 Command-and-Control (C2) Systems of the Program Executive Office for Command, Control, Communications, Computers, Intelligence, and Space (PEO[C4I&S])

C2 System

Abbreviation

Lead Service

Command and Control Processor/Common Data Link Management System

C2P/CDLMS

PEO(C4I&S)

Common Link Integration Processing

CLIP

PEO(C4I&S)

Global Command and Control System Integrated Intelligence and Imagery

GCCS I3

Defense Information

Systems Agency (DISA)

Global Command and Control System-Joint

GCCS-J

DISA

Global Command and Control System-Maritime

GCCS-M

PEO(C4I&S)

Joint Effects Model

JEM

Navy

Joint Operational Effects Federation

JOEF

Army

Joint Protection Enterprise Network

JPEN

Army

Joint Simulation System-Maritime

JSIMS-M

Navy

Joint Interface Control Officer (JICO) Support System

JSS

Air Force

Joint Warning and Reporting Network

JWARN

Army

Multifunctional Information Distribution System-Low Volume Terminal

MIDS-LVT

Navy

MIDS and F/18 Integration

MIDS F/18 Integration

PEO(C4I&S)

MIDS on Ship

MOS

PEO(C4I&S)

Naval Tactical Command Support System

NTCSS

PEO(C4I&S)

Shipboard Automated Medical System Non-Tactical

SAMS NT

PEO(C4I&S)

Theater Battle Management Core System

TBMCS

Air Force

Theater Medical Information Program-Maritime

TMIP-M

PEO(C4I&S)

 

SOURCE: Adapted from date provided to the committee by Andrew Cox, Executive Director, Program Executive Office for C4I and Space, January 31, 2005.

Command, Control, Communications, Computers, Intelligence, and Space (PEO[C4I&S]), but a significant number of programs for C2 systems more directly involved with weapons systems are in the Program Executive Office for Integrated Warfare Systems (PEO[IWS]) and the Program Executive Office for Strike Weapons and Unmanned Aviation (PEO[W]). Table 4.1 lists key C2 systems with which the PEO(C4I&S) is involved. To help operating Marine Corps forces accomplish their warfighting mission, the Marine Corps Systems Command equips them with C2 systems.1 It depends on the PEO(IWS) and the Army for the development of several of these C2 systems.

Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×

Given the number of C2 systems, this study cannot address them individually. Rather, the material below speaks to some general issues about C2 systems and then focuses on what is the most encompassing of the those systems, the Global Command and Control System-Maritime (GCCS-M), and its anticipated follow-on capability, to be provided by a Joint Command and Control (JC2) program. One key component of GCCS-M/JC2 is the COP, which is also discussed below.

4.2.1 Toward a Cohesive View of C2 Systems

The PEO(C4I&S) has recently been reorganized; all C2 systems have been moved into one organization (Program Manager, within the Space and Naval Warfare Systems Command [SPAWAR] for Command and Control Systems [PMW 150]) that now manages not only GCCS-M but also a number of C2 systems that tie more directly to weapons systems. The intent of this reorganization is to allow unified management of all PEO(C4I&S) C2 systems. This approach could allow significant advances and efficiencies in the development of C2 systems. For example, common C2 services that would provide a basis for the individual C2 systems could be developed, thereby simplifying and allowing more rapid development of the individual systems and perhaps even reducing their overall number.

From a cross-PEO perspective, the PEO(C4I&S) and PEO(IWS) have initiated discussions to develop a more common view of C2 across their organizational boundary. This collaboration is necessary, since to some extent the boundary between C2 and combat systems has historically been set arbitrarily. In any event, network-centric operation requires that information flow easily across this boundary. To that end, one specific topic that the PEO(C4I&S) and PEO(IWS) are working on jointly is that of assessing the feasibility of developing a common track manager for use in both C2 and combat systems, drawing on work to date for the Single Integrated Air Picture (SIAP) and Open Architecture Track Manager (OATM). If successful, this track manager will be an important factor in resolving COP inconsistencies between tracks obtained by combat and C2 system sources (e.g., Aegis). Such a development would also be an important input to JC2 development when that commences.

The committee strongly endorses these efforts within the PEO(C4I&S) and between the PEO(C4I&S) and PEO(IWS) to develop a more cohesive overall view of naval C2 systems. Developing this view will be a challenge from both the management and the technical perspectives, but it is necessary in order to provide C2 systems most efficiently and effectively to the fleet. Now is a particularly opportune time to effect the greater collaboration between the PEO(C4I&S) and PEO(IWS), since both parties are in the midst of fundamental reexaminations of their design approaches—the PEO(C4I&S) in terms of moving to JC2 and the PEO(IWS) in terms of its open architecture construct for combat systems.

Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×

4.2.2 Global Command and Control System-Maritime and Joint Command and Control

Global Command and Control System-Maritime

The GCCS-M is the maritime component of the Global Command and Control System (GCCS) family of systems (FOS), which also includes joint, Army, and Air Force components.2 The GCCS-M is deployed on approximately 325 ships and submarines and at 65 ashore and tactical mobile sites. Figure 4.1 depicts the overall configuration of the GCCS-M. The center of the figure shows the functional components of the system; the bands on the left and right show the inputs and outputs of the system. Clearly, the GCCS-M is a very complex system.

The large number of inputs and outputs for GCCS-M means that interoperability across all of these interfaces has been a prime concern for the system. Typically, when a new input or output is identified, specific steps must be taken to integrate this component into the GCCS-M. While the GCCS-M program has largely been successful in these efforts, this approach will not scale to the demands of a network-centric environment in which inputs from or outputs to systems not anticipated in advance can become the norm. A second shortcoming of the GCCS-M, noted to the committee by field members of the fleet, is the complexity of its user interface. That is, significant training is required before an operator can effectively use this system.

Joint Command and Control

The JC2 program is intended to replace the entire GCCS FOS. While there may still be some Service-specific components associated with JC2, the intent is that much more of the overall functionality will be provided through commonly used components. In addition, the intent is to develop JC2 from a modern, Services-based perspective. These two characteristics should lead to a JC2 capability that allows much more ready interaction with external systems.

Since JC2 is not a program yet but rather is in the capability-definition phase, little in the way of specific technical aspects of JC2 exists. At the time of this writing (June 2005), a Capability Description Document exists in draft form, and acquisition Milestone A is anticipated by the end of the summer of 2005. Typically, program initiation is not established until Milestone B, which for JC2 is planned for approximately a year after Milestone A. Following program initiation, the initial increment of JC2 capability (Block 1) is planned to be deployed at the end of FY 2007, with Block 2 at the end of FY 2009, and further increments to follow that.

2  

The Marine Corps does not have a separate component; it uses the joint component.

Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×

FIGURE 4.1 Global Command and Control System-Maritime (GCCS-M) systems view: The GCCS-M is deployed on about 325 ships and submarines and at 65 ashore and tactical mobile sites. NOTE: ACDS/SSDS, Advanced Combat Direction System/Ship Self-Defense System; BGPHES, Battle Group Passive Horizon Extension System; CDF, combat direction finding; CV/TSC, carrier/Tactical Support Center; NAVSSI, Navigation Sensor System Interface; TBMCS/JTT, Theater Battle Management Core Systems/Joint Tactical Terminal; JMPS, Joint Mission Planning System; JSIPS-N, Joint Services Imagery Processing System-Navy; SMS/NAVMACS, Stores Management System/Naval Modular Automated Communications System; COP, common operational picture; ATWCS/TTWCS, Advanced Tomahawk Weapon Control System/Tactical Tomahawk Weapon Control System; AIP, Antisurface Warfare Improvement Program (Maritime Patrol Aircraft [MPA]); TRMS, Type Commanders Readiness Management System. SOURCE: Interoperability Key Performance Parameters (IKPP) Submission to J6 for GCCS-M 4.x by Space and Naval Warfare Systems Command, PMW 157, December 10, 2003.

Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×

This incremental development of JC2, while a sound development process, accounts for one of the problems that must be addressed in transitioning C2 systems—namely, the legacy and the new systems must coexist for some period of time (years in the case of JC2), and the user must be presented with some sort of unified capability. That is, it would be unacceptable if a user had to access GCCS-M for some functionality and then go separately to JC2 for other functionality, since these different functionalities are often used in concert to accomplish an overall task. Thus, JC2 should be architected to provide this unified capability.

The JC2 will be a joint development. One Service or the Defense Information Systems Agency (DISA) will have the lead, but certain components will be assigned to each of the Services for development. These components will be for joint use, not just for Service-specific use as is the case for some of the GCCS FOS components. This situation presents an opportunity and a challenge for the Navy:

  • The opportunity is that the Navy has particular expertise that it can bring to bear in the development of JC2 that would serve the whole joint community. An example is its work in track management.

  • Different Services and joint organizations will have their own interests and needs with respect to what capabilities should be included in each of the JC2 components that are to be used by all parties. The challenge is thus to avoid having the developing party for a given component be unduly biased by its own interests. A particular challenge from the Navy perspective will be that of ensuring that JC2 has the functionality needed for tactical operation. The Navy is the only one of all the Services that uses its GCCS FOS component for tactical purposes at the present time.

Thus, along with the other development partners, the Navy should take an aggressive lead role in JC2 development, both to bring particular naval expertise to bear in supporting the joint community and to ensure that naval needs are met in the development.

Network-Centric Enterprise Services

It is intended that JC2 make use of the Network-Centric Enterprise Services (NCES) being developed by DISA. NCES will be an incremental development like JC2, with Increment 1 development (composed of three spirals) running from the beginning of FY 2006 through FY 2008. This development also presents another opportunity for the Navy to contribute its expertise. In particular, the Office of Naval Research (ONR) has sponsored the development of the Extensible Tactical C4I Framework (XTCF), and the PEO(C4I&S) has sponsored the development of an Enterprise Services Bus (see the discussion below in Section 4.4). These products could serve as interim NCES-like capabilities for both op-

Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×

erational use and prototype exploration, and possibly also for inclusion in the actual NCES suite when it is deployed.

Distributed Common Ground Station

A further, more speculative opportunity may also exist pertaining to the Distributed Common Ground Station (DCGS), which is envisioned to be a family of systems that provides multi-ISR processing and exploitation to the Joint Task Force (JTF) and echelons below. The DCGS Integration Backbone (DIB) and NCES share many common, desired characteristics. The possibility thus exists that the DIB and NCES efforts could collaborate to provide common products, thereby helping to establish closer coupling between C2 and intelligence, surveillance, and reconnaissance (ISR) processing systems. The DIB is being developed by the Air Force, and its first release is now being tested. When that testing is complete, the DIB release and the NCES prototypes referred to in the previous subsection could provide a vehicle for examining the potential for commonality between the DIB and NCES. For the PEO(C4I&S) to work with the DCGS-Navy office, which in turn would work with the DCGS-Air Force office, would be the most direct way to initiate this exploration.

Command and Control at the Operational Level

The Navy C2 systems described above are primarily oriented toward the tactical, not the operational, level of war. Operational-level planning and execution, of course, are not focused on tactical execution, but on the decisions necessary to ensure that the expected successes in tactical execution will eventually lead to the desired end-state of a conflict.

There is a tendency to think that if the C4ISR system can support tactical execution, including the application of joint fires against time-critical targets, then it can support operational-level planning as well. This is not the case. The information needed to support operational-level decision making is more diverse and, in many cases, more focused on sophisticated intelligence than on surveillance and reconnaissance. This is particularly true in supporting operational-level information operations (IO) campaigns.

While C2 presentations to the committee were focused primarily on tactical C2, a recent Defense Advanced Research Projects Agency-Joint Forces Command (DARPA-JFCOM) initiative, the Integrated Battle Command (IBC) program,3 is developing tools to support operational-level decision making. These tools include models to predict the impact of Diplomatic, Information, Military,

3  

Additional information is available at <http://www.darpa.mil/ato/solicit/IBC/index.htm>. Accessed January 26, 2006.

Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×

and Economic (DIME) actions on Political, Military, Economic, Social, Information, and Infrastructure (PEMSI) effects. The models and other tools will assist commanders in generating operational-level campaign plans that encompass the full spectrum of DIME actions and PEMSI effects.

4.3 COMMON OPERATIONAL PICTURE

Tracking data from numerous sources, including weapons systems, organic and nonorganic sensors, and intelligence sources (see Figure 4.1) are inputs to the GCCS FOS (and later to the JC2) to generate the COP as an output. An accurate COP is essential to NCO, as it facilitates the self-synchronization of NCO, decreasing the need for communications to establish a common understanding of a situation and thereby increasing the speed of command. While the COP as it exists today does provide important information, the current system has significant shortcomings. This situation is discussed below according to the four components of the COP—the air picture, the maritime (sea surface) picture, the undersea picture, and the ground picture. But first, there should be some clarification of the nature of a COP.

The word “common” in the term “common operational picture” does not mean that all participants have the same display picture; rather, it means that all participants have access to common sources of data, which could be displayed in different ways depending on the needs and equipment of the particular user. Access to data is the key here. From a network-centric perspective (see the discussion in Chapter 3), users should have access to data as soon as they are in some comprehensible form, even though further processing of the data might be intended. This is because different users will have different needs for the data, and the additional processing might remove information content according to the perspectives of some users. For example, air vehicle tracks could be processed with the criteria of minimizing false-alarm rates or in order to display all potential leakers; the resulting processed data would not be the same in the two cases. Common processing will have to be applied in cases, for example, in which the parties involved need to see the same air picture, but the data should still be accessible in their preprocessed form.

4.3.1 Air Picture

The air picture component of the COP displays the tracks (location and identity, where known) of aircraft, cruise missiles, and ballistic missiles, be they friendly, neutral, or hostile. The particular problems in the air picture relate primarily to aircraft and cruise missiles, given the typically unique and observable nature of ballistic missiles. Shortcomings in the air picture include missing tracks, multiple track designations for one object, swaps of track number between objects, and object misidentification. These shortcomings have been manifest in

Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×

real-world operations and in detailed exercises such as the Joint-Service Combat Identification Evaluation Test (JSCIET) series. They result from such causes as the lack of a common time standard across the force, failure to achieve a common geodetic coordinate frame, differences in correlation/decorrelation algorithms, inconsistent Link 16 datalink implementations, and the lack of connectivity among data links.

Incremental progress has been made in addressing these problems over the years, but a wholly adequate solution may not result unless a new COP for the air picture is designed from the ground up. Work is now being done on components that can be used for such a new development. The PEO(IWS) is developing the OATM and working with the Joint SIAP System Engineering Organization (JSSEO) to obtain a common track manager from the OATM and SIAP. These developments would be integrated into Aegis and the Marine Corps Common Aviation Command and Control System (CAC2S). The CAC2S is being developed to replace the existing C2 equipment of the Marine Air Command and Control System (MACCS), which will provide the Aviation Combat Element (ACE) with the necessary hardware, software, equipment, and facilities to effectively command, control, and coordinate air operations. Furthermore, the PEO(C4I&S) and PEO(IWS) are working to develop a common track manager applicable across their two domains—C2 and combat systems, respectively. Given the development of a common track manager, the issue will be the extent to which this track manager is available throughout the force (all Services) and inadequate legacy track-management capability is phased out.

At the same time, however, as is noted above, the track data prior to processing by the common track manager should be accessible for those who have a need for those data. This requirement has implications with respect to the design of air picture systems in terms of the data interfaces and posting mechanisms that must be provided.

4.3.2 Maritime Picture

The maritime picture component of the COP applies to both the open ocean, which would be of interest in tracking ships suspected of terrorist intent, and to the littorals. Given this study’s focus on the latter environment, only that is considered here. This maritime picture is established from sensor data collected from national assets, aircraft, helicopters, and, in the future, from unmanned aerial vehicles (UAVs). The airborne assets can be both naval and, potentially, those of other Services and coalition parties, too.

Navy officers interviewed during the study indicated that the quality of the current maritime picture, while improving over the past few years, still has significant shortcomings. In particular, sensor coverage typically is not adequate to provide full, persistent coverage, and those sensor inputs that are available are manually assembled rather than being networked together. “Networked” here

Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×

means that the results of different observations on the same target are correlated and that the handoff of tracks between sensors is accomplished reliably in a synchronized, automated manner.

The consequence of these shortcomings is a maritime picture that is far less complete and accurate than it could be. Analyses conducted by the Office of the Chief of Naval Operations (OPNAV) showed that a significantly improved maritime picture would result from networking the sensors. OPNAV staff had formulated a potential program, called the Single Integrated Maritime Picture, to network the sensors providing maritime surveillance, but this proposal was not included in the budget for funding. A program such as that appears necessary to meet the surface threat in the littoral environment, including the possibility of swarms of small boats, particularly given the importance of littoral operations.

4.3.3 Undersea Picture

The undersea picture component of the COP refers primarily to the location and identification of submarines and mines. There are significant shortcomings in the ability to detect quiet submarines and stealthy minefields (see Chapter 7, Section 7.3.1). Means for improving the networking of the undersea sensors also appear necessary, but the first priority is the need to improve the sensor detection and processing.

4.3.4 Ground Picture

Those aspects of the ground picture component of the COP pertaining to a direct interaction of Marine Corps forces with hostile forces ashore are not considered here. The reason is that the scope of this study does not include the operational maneuver of Marine Corps forces ashore except for those aspects of the ground picture necessary for naval fires from or directed by expeditionary strike groups against ground targets in support of Marine Corps (and other Service or coalition) forces.4

The distance inland that must be surveilled will increase greatly in the future as longer-range weapons for naval fires are deployed. This ground picture includes friendly, neutral, and hostile entities. The identification and location of

4  

The Advanced Field Artillery Tactical Data System (AFATDS) is an automated fire-support C2 system. AFATDS automates the fire planning, tactical fire direction, and fire-support coordination required to support maneuver from the sea and subsequent operations ashore. The Automated Deep Operations Coordination System (ADOCS) is a joint mission-management software application. It provides a suite of tools and interfaces for horizontal and vertical integration across battlespace functional areas. ADOCS has evolved into the automated support system in actual wartime situations for deep operations in several theaters. ADOCS is the baseline for the Naval Fires Control System (NFCS).

Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×

U.S. ground forces have recently improved greatly with the use of blue force tracker systems. The trackers used by the Marines are not yet part of a program of record, and interoperability problems exist between tracker types, although actions appear to be under way to resolve these issues.

The Navy is largely dependent on the sensors of other Services and on intelligence means to provide information on coalition, neutral, and hostile entities for the ground picture, although the Navy does have some applicable organic sensors (see Chapter 7, Section 7.3). At the present time there is no funded program—joint or in any of the Services—to provide a composite ground picture on which the Navy can draw. An effort referred to as the Single Integrated Ground Picture (SIGP) was recently initiated by the Office of the Secretary of Defense (OSD), but the status of this effort is unclear as of this writing. In the face of this uncertainty, the Navy should ensure that it has the necessary external inputs, and that these inputs can be correlated with organic Navy inputs, to provide it with the necessary ground picture. As all the Services and intelligence entities move toward network-centric operations and post their sensor and other data, input from the external sources should become readily available to the Navy. Still, there remains the issue of the adequacy of coverage provided by the organic and nonorganic sensors; Chapter 7, “Intelligence, Surveillance, and Reconnaissance,” indicates that there are significant shortcomings in that coverage.5

4.4 COMMAND AND CONTROL WITH SERVICE-ORIENTED ARCHITECTURES

Service-oriented architectures (SOAs) is a relatively new concept. As concluded by a previous NSB committee6 and discussed in Chapter 5, Section 5.7, of this report, work is need to evaluate emerging commercial SOA products and

5  

Previous Naval Studies Board reports have pointed out this type of deficiency. See Naval Studies Board, National Research Council, 1988, Implications of Advancing Technology for Naval Operations in the Twenty-First Century, Vol. 1: Overview, National Academy Press, Washington, D.C., p. 77; Naval Studies Board, National Research Council, 1991, Future Aircraft Carrier Technology, Vol. 1: Overview, National Academy Press, Washington, D.C., pp. 78-79; Naval Studies Board, National Research Council, 1997, Technology for the United States Navy and Marine Corps, 2000-2035: Becoming a 21st-Century Force, Vol. 1, Overview, pp. 55 and 59; and Vol. 3, Information Warfare, p. 97, National Academy Press, Washington, D.C.; Naval Studies Board, National Research Council, 2000, Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities, National Academy Press, Washington, D.C., pp. 100, 107, and 135; Naval Studies Board, National Research Council, 2001, Naval Forces’ Capability for Theater Missile Defense, National Academy Press, Washington, D.C., p. 7.

6  

Naval Studies Board Committee on FORCEnet Implementation Strategy (National Research Council. 2005. FORCEnet Implementation Strategy, The National Academies Press, Washington, D.C., p. 174).

Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×

concepts, to determine how best to apply these concepts to C2, to mature the technology, and to address unique requirements for military C2. As that committee observed, SOA is a prospectively powerful technical infrastructure for composing forces “on the fly” to respond rapidly to new threats and to streamline the force buildup required to conduct military operations. That committee also noted, however, that building this technical infrastructure for network-centric operations is an exceptionally large undertaking. It recommended that the Department of the Navy actively “engineer the vision” to ensure that emerging commercial standards and their adoption throughout the naval forces deliver coherent and interoperable C2 systems.

4.4.1 Navy Research in Service-Oriented Architecture for Command and Control

The Navy has several ongoing research programs related to SOA for C2. The programs, with the responsible organization for each, are listed and discussed below.

  • Composable FORCEnet—SPAWAR,

  • FORCEnet Engagement Packages—SPAWAR,

  • Extensible Tactical C4I Framework—ONR,

  • Enterprise Services Bus (ESB)—SPAWAR, and

  • Joint Coordinated Real-Time Engagement (JCRE)—ONR.

Composable FORCEnet

Composable FORCEnet is a crucial extension to the FORCEnet principle. Composable FORCEnet is the ability to select on the fly from a vast network specific information resources that are best suited to solving a particular problem or providing specific information (Figure 4.2).

The implementation of a composable FORCEnet must provide several overarching capabilities:

  • The ability to identify participants in the battlespace and to determine their organic capabilities and needs. The Air Force Joint Battlespace Infosphere (JBI) has developed a concept called the Force Template to support on-the-fly identification of participants, their capabilities, and their constraints.7

  • The ability to assemble the participants within a coalition working toward a common mission objective. Added here is that this capability includes the

7  

A prototype was demonstrated in 2002 at Air Combat Command Headquarter’s Combined Air Operations Center-Experimental to the Naval Studies Board’s Committee on the Role of Experimentation in Building Future Naval Forces.

Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×

FIGURE 4.2 A representation of composable FORCEnet. SOURCE: Adapted from George Galdorisi, Jeffrey Grossman, Michel Reilley, Jeffrey Clarkson, and Christopher Priebe, 2004, Figure 10: Composeable FORCEnet’s Concept of Plug and Fight, in Composeable FORCEnet Command and Control: The Key to Energizing the Global Information Grid to Enable Superior Decision Making, presented at the Power of Information Age Concepts and Technologies Symposium (part of the 2004 Command and Control Research and Technology Sym posium), held in San Diego, Calif., June 15-17. NOTE: JMF, Joint Mission Force; Intel, intelligence; METOC, meteorological and oceanographic; OMFTS, Operational Maneuver From the Sea.

Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×

ability to work in participants who may be available for only a fraction of a coalition’s lifetime. SPAWAR is developing a force composition concept called FORCEnet Engagement Packages for this purpose.

  • The ability to exchange information within the coalition. ONR is developing the XTCF to provide this capability.

  • The ability to establish new concepts of operation (new ways of doing business) that are consistent with the capabilities and constraints of the participants. SPAWAR is looking at field-configurable work-flow management, with particular attention to the Business Process Execution Language (BPEL). SPAWAR has developed an architecture framework called the Enterprise Services Bus to implement field-configurable work flow.

  • The ability to introduce new capabilities to the coalition, either by adding functionality to existing coalition members or by adding new participants to the coalition.8

SPAWAR has conducted some early analysis on the mission value of a rapidly composable force for ad hoc warfare. The preliminary results indicate increased combat reach in selected scenarios:9

  • A 40 percent better utilization of blue (friendly) assets in antisubmarine warfare (ASW) and offensive counter-air (OCA),

  • A 40 percent improvement in Theater Air and Missile Defense (TAMD) kills against massive raids,

  • A 50 percent reduction in the number of leakers,

  • A 100 percent increase in the interception range of the engagement envelope, and

  • Up to a tenfold increase in the percentage of overland area protected.

FORCEnet Engagement Package

A FORCEnet Engagement Package (FnEP) is a portfolio of the capabilities that participants bring to a fight. A portfolio is linked to specific mission areas that the participant(s) can support. Participants, here, can range from single entities to multiple entities constituting a larger organization. Figure 4.3 illustrates a specific FnEP for a notional collection of participants. The rows represent distinct participants; the columns represent capabilities and the specific subsystems

8  

There is also the need for this kind of composing capability when all systems are not working—that is, not only when assets are added but also when they are subtracted from a force.

9  

Phillip Charles. 2004. “FORCEnet Engagement Packs and Net-Centric Operations,” presentation, SPAWAR System Center, Charleston, S.C., April 7.

Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×

FIGURE 4.3 A FORCEnet Engagement Package is defined by its constituent participants (rows), the capabilities that they possess (columns), and the information exchanges between them. NOTE: CT, cooperative track; CTP, common tactical picture; ABMA, Army Ballistic Missile Agency; IFC, integrated fire control; CCID, coalition combat identification; COP, common operational picture; MP, mission plan; PNT, positioning, navigation, and timing; MC, mission control. SOURCE: Courtesy of SPAWAR Systems Center, Charleston, S.C.

that provide them. Figure 4,3 shows an arrangement of four participants, all providing sensors, two providing weapons, three providing C2 capabilities to different degrees, and two providing targeteers and/or weapon controllers. The wiring shows the information flows between the participants and the subsystems. The FnEP is defined by both the platform types (including their organic capabilities) and the wiring between them. A different wiring arrangement and/or a different collection of participants would define a different FnEP.

The FORCEnet Engagement Package concept is in its formative stages. It has not been demonstrated in experiments or exercises involving actual platforms. In addition, the concept is dependent on additional capabilities that are themselves only beginning to emerge or mature, including the following:

  • The ability to discover the available participants on the fly through a registry. This is the objective of the Force Template concept described in the previous subsection. This Air Force program is making inroads but has not enjoyed the consistent funding required to move beyond the concept-formulation stage.

  • The ability to compose an Engagement Package. This is a nontrivial problem that requires a thorough analysis of all the factors that determine whether

Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×

the participants will work in unison. One can expect that the analysis effort will grow exponentially with the number of participants that constitute an Engagement Package. Moreover, the analysis required to compose a properly working Engagement Package increases further still if participants are available for only a fraction of the package’s lifetime. The committee is not aware of Navy investments toward providing a a capability to compose an Engagement Package.

  • The ability to orchestrate the execution of the Engagement Package. This is one of the objectives of SPAWAR’s ESB, discussed in the subsection below entitled “Enterprise Services Bus.”

Extensible Tactical C4I Framework

The XTCF (Program Element 0602235N) is being developed under the Knowledge Superiority and Assurance Future Naval Capability Program of ONR. The XTCF permits the exchange of data between different C2 systems through the use of loosely coupled, distributed, reusable, standards-based services. It uses the following Web services technologies:

  • Extensible Markup Language (XML) to describe information. Composable C2 requires a means for describing data, for establishing data dictionaries, and for identifying logically equivalent types of data10 XML provides these means and is the de facto standard used by modern service-oriented architectures;

  • Web Services Description Language (WSDL) to describe the interfaces to services. Composable C2 requires a means for identifying services, for identifying equivalent types of services, and for invoking those services. WSDL lets the members of an enterprise describe the services they provide at multiple levels of abstraction to improve the chances that a service client will be able to (1) locate a satisfactory service provider and (2) invoke the service. WSDL also provides the means to convert abstract service descriptions and abstract service invocation methods into the specific messages required to communicate with the specific service providers present in an enterprise at any given time;

  • Simple Object Access Protocol (SOAP) to access Web services; and

  • Universal Description, Discovery and Interoperability (UDDI) to register and locate Web services.

10  

Besides data, there will have to be judgments made about readiness, rules of engagement, and willingness to engage, for example, by coalition forces. The view that because of the generally different “qualities” of data being fused, it will be difficult to do away with human judgment in many, if not most, cases is expressed by ADM W.J. Holland, USN (Ret.), 2003, “What Really Lies Behind the Screen,” U.S. Naval Institute Proceedings, Vol. 129, April, p. 73.

Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×
Enterprise Services Bus

The Enterprise Services Bus is the product of SPAWAR’s Distributed Services Commercial Area Announcement. The ESB is a paper design, at present, for integrating an SOA with field-configurable work-flow management. The ESB provides a set of core, enterprise, and mission-specific services:

  • Authentication and authorization services, which isolate identity-management solutions from the bus;

  • A registry service for registering distributed services;

  • A publish-and-subscribe messaging/alert service for information flow;

  • A work-flow orchestration service based on a commercially available BPEL server from Collaxa, Inc.;

  • Commercial and open-source portal products;

  • A set of legacy and mission applications comprising mission planning, medical, strike packages, hazardous plume analysis, logistics, and weather information; and

  • A set of authoritative data sources for medical information and blue forces intelligence.

One of the transformational capabilities provided by the ESB is the work-flow orchestration service. This service, implemented using BPEL for Web Services (BPELWS) is based on web-enabled work-flow management standards originally developed by IBM (Web Services Flow Language—WSFL) and Microsoft (XLANG). Operational users can compose their work-flow rules to describe the activities that must be performed to execute a mission thread,11 the services that they require in order to carry out those activities, and the preconditions, postconditions, and triggers for those activities. Services and triggers can link to other mission threads, thereby making it possible to compose system-level (e.g., platform-level) work flows from component-level work flows, and family-of-system-level (e.g., force-level) work flows from system-level work flows. Operational users can compose these rules at any time: during the workup of a force, during the deployment of a force, or in real time. The binding of the abstract services defined in the work-flow rules to specific services is done at runtime using service discovery (e.g., UDDI) and service access (e.g., SOAP) methods.

Figure 4.4 illustrates a BPEL work flow for a representative target-develop-

11  

A mission thread analysis focuses in on a selected/defined mission area and decomposes that mission into functions/tasks to be accomplished, who does them, and what information is required. It allows the analyst to focus on a specific area to ensure that the needs of each mission are addressed within the model. System architects can use the mission thread as a quick means of ensuring they have identified critical C4ISR equipment needs.

Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×

FIGURE 4.4 A target-development work flow expressed using BPEL.

ment process that culminates in a decision about whether or not to engage a prospective target. The objective of this thread is to assemble a comprehensive strike plan, including persistent ISR support. Work-flow rules determine which activities (circles) need to be executed and when, including branching points to parallel activities and convergence (collection) points to serial activities. The specific services that execute those activities—for example, confirming target identity—are discovered at runtime, and are shown as shaded. There does not appear to be any commonality between XTCF and the ESB other than their use of commercial standards for Web services.

Joint Coordinated Real-Time Engagement

The objective of the JCRE, an Advanced Concept Technology Demonstration (ACTD) (Program Element 0603235N), is to demonstrate concepts for force synchronization, both for premission execution targeting and for targets of opportunity discovered on the fly:

Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×
  • Define mission needs and time lines,

  • Define resources required,

  • Request resources, and

  • Approve or disapprove resource requests.

JCRE provides the operational concepts and software to enable joint real-time operations and engagement across multicombatant command theaters and echelons. It will permit Joint Force Commanders to synchronize and employ military efforts rapidly and effectively to conduct globally time-constrained operations. Figure 4.5 illustrates the JCRE implementation concept. JCRE provides the following:

  • Global Situational Awareness Services. These services permit friendly participants to discover each other and to form communities of action (COAs) on the fly in order to achieve a common objective. The foundation for these services is DISA’s User Defined Picture Concept (UDPC), which is being developed under the Net-Centric Capabilities Pilot program. The objective of the UDPC is to provide up-to-date, actionable information to decision makers. The UDPC will let operators create tailored requests for information collection and will tie the collection responses to decision windows.

  • Global Resource Management Services. These services provide for the mutual exchange of capability information that each participant provides, including composition, on-scene and en route assets, and current status (including but not limited to location, health, mission tasking, and availability). These services allow commanders and force providers to establish the capabilities required to execute a mission and to propose or nominate specific capabilities to meet those requirements.

  • Global Synchronization Services. These services help the distributed participants of a COA orchestrate their plans, schedules, and activities to achieve a common objective. They provide the participants of a COA with the ability to define and manage synchronization points. These include meeting points, time dependencies, ISR support constraints, fire-support constraints, and force maneuver synchronization.

The JCRE will conduct a series of demonstrations during FY 2005 to FY 2007 to test and refine these services: in FY 2005 a laboratory exercise was carried out to demonstrate coordinated COA formation and coordinated situational awareness; in FY 2006 a command post exercise will be conducted to demonstrate coordinated force synchronization and coordinated resource management; and in FY 2007 a field exercise will take place to demonstrate interactive coordinated force synchronization and resource management.

Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×

FIGURE 4.5 Joint Coordinated Real-Time Engagement provides software and tactics, techniques, and procedures to enable Joint Force Commanders to synchronize operations and to employ global capabilities and effects rapidly. NOTE: IMD, Integrated Missile Defense; IO, Information Operations; ISR, intelligence, surveillance, and reconnaissance; SOF, Special Operations Forces. SOURCE: Susan Hearold, Office of Naval Research, “Concepts and Technology for a Joint Coordinated Real-Time Engagement (JCRE) ACTD,” presentation to the committee, October 22, 2004.

Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×

4.4.2 Beyond Service-Oriented Architectures: Model-Driven Architectures and Algorithms

Service-oriented architectures address a fundamental C2 requirement: that of allowing users to configure systems rapidly, employing a collection of preexisting services. However, what if the available services do not satisfy the needs of the user but need modification? The Object Modeling Group (OMG) has been developing a technology referred to as Model-Driven Architecture (MDA), that addresses this problem: it permits the rapid modification of applications software deployed across a variety of computing platforms. DARPA is taking this approach a step farther, allowing C2 of new capabilities (sensors and weapons) employing new concepts of operations without any modifications to the source code.

Model-Driven Architectures

The rapid advance of transaction processing across the Internet, together with the advent of business-to-business processing and work-flow synchronization, made clear that middleware alone would not be able to ensure interoperability and software reuse. Middleware emerged in the early 1990s for purposes of integrating applications and moving information between them. Middleware automated the “plumbing” between applications, but it did not automate the system engineering that was required beforehand to determine how that plumbing should run from one application to the next. Those wiring diagrams were still developed on paper, as it were, and they did not lead directly to implemented systems. (The availability of computer-aided design tools for business process engineering notwithstanding, the fungible products from those tools were simply blueprints, not assembled systems.) Systems engineers needed automated tools to actually assemble executable systems from their designs, resulting in the concept of an MDA.

The OMG’s MDA provides a rigorous separation of an enterprise’s business rules from the platforms that carry out those rules to conduct business. “Platform” here refers to computing infrastructure: the operating system, the hardware, the middleware (not an aircraft, land vehicle, or ship). Systems engineers build a Platform Independent Model (PIM) to describe how an enterprise carries out its business: its rules, its data, the services that it provides, and the services that it consumes. The PIM is expressed in Unified Modeling Language (UML), which has become the de facto standard for designing and implementing software. The PIM for a system, then, is expressed in the very same language that will be used to develop the system, providing a direct path leading from the design of a system to its implementation.

An instantiation of PIM that actually executes the enterprise’s business rules in the real world is called a Platform Specific Model (PSM). The PSM can be unambiguously generated from the PIM because the PIM itself is specified in an execut-

Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×

able language. The PSM is the PIM functionality combined with platform-specific interfaces and services. Finally, the PSM is used to generate a Platform-Specific Implementation (PSI), that is, the actual excutable code. The PIM, instead of a paper specification, is provided to the component developers, and their job becomes the development of PSM and PSI for their computing platform or platforms. This task can be heavily automated, supported by commercially available tools.

The MDA approach has a number of advantages for the implementation of C2 systems. First, the PIM guarantees that all PSMs derived from it have a common capacity to execute the enterprise’s business rules: PSMs can be substituted for each other, although possibly with some differences in performance owing to differences in their platforms.

Second, the PIM can be used to test the functionality of the distributed system of systems prior to its implementation. This is accomplished by generating a PSM or PSMs for the computing platform or platforms of a simulation environment. Errors in the PIM can be found in this way by simulation testing prior to the implementation and testing with the real systems.

Third, changes in the system of systems, whether because of errors, advances in algorithm technology, or increases in functionality from a spiral development effort, can be readily accommodated by changes to the PIM. The correctness of these changes can be verified by simulation prior to the dissemination of the revised PIM to the individual system developers. Since the system developers have a process for translating from the PIM to the PSI, the required changes to their systems can be made quickly, at low cost, and with small potential for error.

Fourth, the use of a PIM isolates the system of systems from changes in computing platform technology. If, for example, an individual system developer wishes to move from a proprietary architecture to an open architecture, the developer needs simply to update his or her process for generating a PSI from the PIM.

The MDA approach shows great promise. It has been successfully employed in several large-scale commercial and military systems (notably, the F-16 mission software developed by Lockheed Martin) and is being used by the Joint SIAP Systems Engineering Office in the SIAP program. However, the MDA technology base is still evolving. For example, standards have not matured to the point that different vendors’ tools are fully interoperable.

Model-Driven Algorithms

DARPA’s Information Exploitation Office (IXO) is extending model-driven development into territory beyond MDA in a number of its programs, under the rubric of “agile architectures.” For example, under the Heterogeneous Urban Reconnaissance, Surveillance, and Target Acquisition (RSTA) Team (HURT) program, researchers are developing a system using model-based control algorithms to control a set of UAVs. A challenging problem for the researchers is to

Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×

demonstrate that they can adapt the system to include a new UAV not in the design set within a 10 day period.12

The DARPA/IXO Joint Air/Ground Operations: Unified, Adaptive Replanning (JAGUAR) program is also using a model-based approach to achieve architectural agility. The objective of JAGUAR is to transform the pace of operations at air operations centers to “the speed of thought.” JAGUAR is embedding knowledge-based plan-development capabilities within a stochastic, dynamic control framework, to create a system that is self-aware, adaptable, and agile, and that scales to large problems and intricate domains.

The idea is to capture in models everything known about entities in a battlespace: how they move, how they interact with other entities, how they are vulnerable, how they are secure, and so on. Once calibrated to respond as its real-life counterpart, a model of an entity can be joined with models of other entities to carry out cooperative tasks—for example, to defeat threats.

The most striking aspect of a model-based system is its ability to discover, on its own, new and novel ways of accomplishing tasks. One does not script in a tactic or a rule to accomplish a task in a model-driven system. Rather, one specifies the desired end-state of the task, the constraints in getting to that end-state, the resources (including time) available, the environment (including neutral and deliberately hostile entities), and models for how they all interact.13 JAGUAR’s dynamic control framework (Figure 4.6) discovers ways to obtain the task end-state, sometimes “discovering” approaches that are used by accomplished human planners and sometimes discovering approaches that have never been practiced.

4.5 TRANSITIONING LEGACY COMMAND-AND-CONTROL SYSTEMS TO A NETWORK-CENTRIC ENTERPRISE

A successful and timely transformation of naval C2 capabilities to meet the challenges of the operational environment in the 21st century and the needs of flexible, composable strike groups represents a multidimensional task. Critical aspects include the following:

  • Architecture. The enterprise, node, and system architecture attributes discussed in Chapter 3 must be instantiated in new and modernized hardware and

12  

This is within a design set comprising a limited number of UAVs. To add a new UAV to a design set comprising more than that limited number is much more difficult.

13  

See also Section 6.3.6, “Validating the Architectures by Testing,” stating that wartime communications simulation is difficult.

Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×

FIGURE 4.6 DARPA’s JAGUAR program uses models of objectives, entities, and the environment to discover new and novel ways to accomplish tasks. NOTE: JAGUAR, Joint Air/Ground Operations: Unified, Adaptive Replanning; SPIN, special instruction. SOURCE: Robert R. Tenney, Defense Advanced Research Projects Agency, “C4ISR Technology Initiatives and Trends: A DARPA Perspective,” presentation to the committee, October 22, 2004.

software that implement enterprise, communities of interest (COIs), and local services and conform to the GIG architecture, the Net Centric Operations Warfare Reference Model (NCOW RM), the Net-Centric Data Strategy, and other architecture governance.

  • Technology. The evolving C2 environment must be able to exploit rapidly changing technologies drawn from both commercial and government sources

Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×

while maintaining backward compatibility and enabling fine-grained technology refreshment and system upgrading.

  • Process. An evolutionary methodology that preserves continuity of capability and fits within available resources while progressively migrating C2 systems to the new network-centric paradigm is essential.

  • Doctrine, tactics, techniques, and procedures. While the purely technical side of C2 transformation is under way, the users of these capabilities need matching evolution in their shared understanding of C2 operations; this matching evolution needs to include training, experimental validation, manuals and instructions, and policies.

The Navy has been confronting these challenges for some time. As combined air, surface, and submerged platforms have come to rely increasingly on communications and information processes, the need for common, interoperable C2 systems has become acute. To achieve this, both architectural initiatives such as FORCEnet and implementation approaches such as the Distributed Engineering Plant (DEP) and the Joint Distributed Engineering Plan (JDEP) have been tried, with the primary focus on the principal deployed-force increment—the carrier battle group. Even so, the time involved in fielding significant new C2 systems and a common, updated software load, even across a single battle group, is longer than is compatible with the future strike group vision. Factors contributing to the amount of time required include the need for technology refreshment of information system infrastructures and the implementation of new services, the integration of new hardware and mission service software, the correction of interoperability shortfalls, and crew training, both on individual platforms and for coordinated battle group operations.

As operations become information-intensive, an inescapable consequence is the growing interaction, collaboration, and dependency among COIs, nodes, and systems. This is true within a strike group, among the components of a joint task force, and across the GIG. The results of this integration will be greatly enhanced operational capability with constrained resources, but it necessarily complicates the transition from legacy to future C2 systems, because changes anywhere have effects everywhere. A holistic, architecture-based approach that accounts for dependencies and has the tools to balance and optimize C2 implementations across the fleet is required. Those tools should include executable architectures at operational, process, and physical levels of abstraction, validated and calibrated with data from operations and experiments,14 continuing to build on current analysis efforts.

The information technology community’s approach to this class of migration

14  

The negative side, that is, the loss of components, needs examination as well as the positive side.

Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×

challenge is the evolutionary spiral process. This strategy rejects as infeasible one massive upgrade involving the wholesale replacement of legacy systems with new ones. Rather, a carefully sequenced and adaptable succession of smaller changes is undertaken, guided by operational priorities and the realities of budgets and fleet schedules.

Any given spiral proceeds through requirements analysis, architecture and design, implementation, and test and evaluation to yield an increment of capabilities. The result should be thoroughly tested in fleet experiments to ensure operational effectiveness and supportability. Once validated and approved, the resulting set of changes can be rolled out across the fleet during scheduled maintenance or while deployed, as appropriate, and the results of each spiral form the foundation for planning and executing the next.15

Any Navy C2 evolution strategy will be carried out in an environment of constantly evolving joint operational and architectural policies and mandates. The U.S. Joint Forces Command (USJFCOM) is now chartered to represent the joint warfighting community in developments such as the JC2 system family and to steer overall C4ISR evolution through instruments such as the Joint Battle Management Command and Control (JBMC2) roadmap. Decisions about overall directions and the fate of individual systems will depend heavily on the outcomes of a variety of force experiments, as well as on the lessons learned in ongoing operations. Experience gained in large-scale force experiments such as the biennial Joint Expeditionary Force Experiment (JEFX) series carries a lot of weight in decisions on developing new systems and on migrating or retiring existing ones. At the same time, the OSD is aggressively driving transformation under the overarching rubric of the GIG toward a common network-centric vision. The Navy will be profoundly affected by the doctrine, standards, resource allocations, and other aspects of this DOD-level activity. It is very much in the Navy’s corporate interest to ensure that decisions in the joint arena fully meet the fleet’s needs and support the Navy’s own transformational strategy and priorities. The best way to do that is through involvement and leadership, supported by data from the Navy’s own testing and experiments, especially Sea Trial.

The committee believes that success in transitioning from the current C2 environment to the one demanded by the operational tasks, threats, and force structures of the coming decades depends on a comprehensive, consistent, long-term strategy. That strategy must be network-centric to implement the overall DOD information architecture and to remain executable in the real world of budgets and operational commitments.

15  

The capability status will generally be nonuniform within the strike groups at any given time.

Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×

4.6 FINDINGS AND RECOMMENDATIONS

Finding: The current Global Command and Control System family of systems (GCCS FOS) has significant shortcomings, particularly in its ability to accommodate new information sources and new output users. The Joint Command and Control (JC2) system, supported by Network-Centric Enterprise Services (NCES) and planned as a joint development effort, is intended to address these shortcomings.


Recommendation: The Program Executive Officer for Command, Control, Communications, Computers, Intelligence, and Space (PEO[C4I&S]), in conjunction with the Deputy Chief of Naval Operations for Warfare Requirements and Programs (N6/N7) and the Assistant Secretary of the Navy for Research, Development, and Acquisition (ASN[RDA]), should be an active participant in JC2 development, both to bring the particular expertise of the PEO(C4I&S) to bear in developing the joint capabilities and to ensure that the Navy’s needs are met in the joint development. Further opportunities also exist for the Navy to prototype NCES capabilities and possibly to effect a synthesis between NCES and Distributed Common Ground Station (DCGS) Integration Backbone capabilities.


Finding: Current air pictures as a component of the common operational picture have significant shortcomings in the completeness and consistency of tracks shown for air vehicles. In addition, the input to current maritime pictures is correlated manually, resulting in significant shortcomings in the ability to effect the correlation of maritime-related information, and hence in the completeness and accuracy of the resultant maritime picture supporting littoral operations. The Navy is working to address the air tracking problems through its OATM development and collaboration with the JSSEO SIAP development, but it has established no program to address the problems with the maritime picture.


Recommendation: The PEO(IWS), in conjunction with the PEO(C4I&S), should continue its efforts to develop a common air track manager from OATM and SIAP. This common air track manager should be designed so that the data prior to track-manager processing are accessible, since some parties may require access to information that could be lost in track-manager processing. For the maritime domain, the N6/N7 should establish a program to develop the automated networking of sensors feeding the maritime picture necessary for littoral operations. In all of this work, the Navy should ensure that the track managers and related capability developments also (1) contribute to meeting the needs of the joint force, including working with Missile Defense Agency products, and (2) support related developments (e.g., ground pictures) in other Services.

Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×

Finding: While the Office of Naval Research is conducting valuable research at the component level, system-of-systems integration to provide flexible and adaptive command and control (C2) is an area of limited emphasis, although it may in fact be the most critical C2 technology need.


Recommendation: The Chief of Naval Research should develop a research program, with an associated transition plan, to develop, evaluate, and mature system-of-systems integration technology for providing flexible and adaptive C2. In conducting this research program, the time to adapt algorithms, software, and systems to new capabilities, threats, and concepts of operations not in the initial design space should be a key measure of performance. The research should encompass emerging commercial technologies for enterprise integration and for the development of computing-platform independent applications as well as emerging concepts such as agile architectures under development at the Defense Advanced Research Projects Agency (DARPA) and other government research agencies.


Finding: The transition from legacy to modern C2 systems will be a difficult challenge for the Navy for several reasons: (1) The task is multidimensional, involving multiple architectural, technological, process, and operational factors; (2) the time to work up and transition to new C2 systems takes a long time; (3) backward compatibility is rarely demonstrated until system(s) exit development laboratories; (4) complex system interdependencies lengthen every stage of the transition life cycle; and (5) the time required to integrate, test, and accredit new systems delays the fielding of new capabilities and complicates the management of fleetwide C2 evolution.


Recommendation: N6/N7 should prioritize the missions that will be made network-centric and identify the community of interest (COI) services and metadata standards that they require. N6/N7 thus should carry out the following:

  • Develop executable architectures to design and develop those COI services;

  • Build a spiral acquisition program encompassing the incremental and periodic integration of network-centric prototypes, test them using the Distributed Engineering Plant (DEP) (or possibly the Joint Distributed Engineering Plant [JDEP]) and Sea Trial; and

  • Use the results of spiral acquisition to influence the maritime component of JC2.

Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×
Page 104
Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×
Page 105
Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×
Page 106
Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×
Page 107
Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×
Page 108
Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×
Page 109
Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×
Page 110
Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×
Page 111
Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×
Page 112
Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×
Page 113
Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×
Page 114
Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×
Page 115
Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×
Page 116
Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×
Page 117
Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×
Page 118
Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×
Page 119
Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×
Page 120
Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×
Page 121
Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×
Page 122
Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×
Page 123
Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×
Page 124
Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×
Page 125
Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×
Page 126
Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×
Page 127
Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×
Page 128
Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×
Page 129
Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×
Page 130
Suggested Citation:"4 Command-and-Control Systems." National Research Council. 2006. C4ISR for Future Naval Strike Groups. Washington, DC: The National Academies Press. doi: 10.17226/11605.
×
Page 131
Next: 5 Computers »
C4ISR for Future Naval Strike Groups Get This Book
×
Buy Paperback | $65.00 Buy Ebook | $54.99
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

The Navy has put forth a new construct for its strike forces that enables more effective forward deterrence and rapid response. A key aspect of this construct is the need for flexible, adaptive command, control, communications, computers, intelligence, surveillance, and reconnaissance (C4ISR) systems. To assist development of this capability, the Navy asked the NRC to examine C4ISR for carrier, expeditionary, and strike and missile defense strike groups, and for expeditionary strike forces. This report provides an assessment of C4ISR capabilities for each type of strike group; recommendations for C4ISR architecture for use in major combat operations; promising technology trends; and an examination of organizational improvements that can enable the recommended architecture.

  1. ×

    Welcome to OpenBook!

    You're looking at OpenBook, NAP.edu's online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

    Do you want to take a quick tour of the OpenBook's features?

    No Thanks Take a Tour »
  2. ×

    Show this book's table of contents, where you can jump to any chapter by name.

    « Back Next »
  3. ×

    ...or use these buttons to go back to the previous chapter or skip to the next one.

    « Back Next »
  4. ×

    Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

    « Back Next »
  5. ×

    Switch between the Original Pages, where you can read the report as it appeared in print, and Text Pages for the web version, where you can highlight and search the text.

    « Back Next »
  6. ×

    To search the entire text of this book, type in your search term here and press Enter.

    « Back Next »
  7. ×

    Share a link to this book page on your preferred social network or via email.

    « Back Next »
  8. ×

    View our suggested citation for this chapter.

    « Back Next »
  9. ×

    Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

    « Back Next »
Stay Connected!