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



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



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

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

OCR for page 104
C4ISR for Future Naval Strike Groups 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

OCR for page 104
C4ISR for Future Naval Strike Groups 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. 1   See <http://www.marcorsyscom.usmc.mil/sites/syscomorg/MC21_MAGTF_C2.asp>. Accessed January 26, 2006.

OCR for page 104
C4ISR for Future Naval Strike Groups 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.

OCR for page 104
C4ISR for Future Naval Strike Groups 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.

OCR for page 104
C4ISR for Future Naval Strike Groups 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.

OCR for page 104
C4ISR for Future Naval Strike Groups 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-

OCR for page 104
C4ISR for Future Naval Strike Groups 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.

OCR for page 104
C4ISR for Future Naval Strike Groups 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

OCR for page 104
C4ISR for Future Naval Strike Groups 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

OCR for page 104
C4ISR for Future Naval Strike Groups 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).

OCR for page 104
C4ISR for Future Naval Strike Groups 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).

OCR for page 104
C4ISR for Future Naval Strike Groups 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:

OCR for page 104
C4ISR for Future Naval Strike Groups 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.

OCR for page 104
C4ISR for Future Naval Strike Groups 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.

OCR for page 104
C4ISR for Future Naval Strike Groups 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-

OCR for page 104
C4ISR for Future Naval Strike Groups 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

OCR for page 104
C4ISR for Future Naval Strike Groups 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.

OCR for page 104
C4ISR for Future Naval Strike Groups 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

OCR for page 104
C4ISR for Future Naval Strike Groups 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.

OCR for page 104
C4ISR for Future Naval Strike Groups 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.

OCR for page 104
C4ISR for Future Naval Strike Groups 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.

OCR for page 104
C4ISR for Future Naval Strike Groups 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.