4
Designing a Common Command and Information Infrastructure

This chapter begins by articulating the concept of a common command and information infrastructure for the naval forces, the Naval Command and Information Infrastructure (NCII). In particular, Section 4.1 notes the general attributes that the NCII should possess, including adaptability in the face of changing needs and new technologies, and the functional capabilities it should provide to support users. The NCII supports all echelons—strategic, operational, and tactical—with a uniform architecture that uses commercial network protocols, a concept that, for tactical networks, runs contrary to the current situation. Section 4.2 develops this important point, and it is further elaborated on in Appendix E. Since an architecture is key to realization of the NCII, Section 4.3 discusses the products and processes the Department of Defense (DOD) and the Department of the Navy currently use for developing architectures and comments on their suitability for developing an NCII architecture. Section 4.4 gives the committee’s recommendations based on the material presented in the preceding three sections.

4.1 THE NAVAL COMMAND AND INFORMATION INFRASTRUCTURE CONCEPT

4.1.1 Definition and Properties

The broad and rapid exchange of information and the ready assimilation and use of this information are at the heart of network-centric operations (NCO). In NCO, the individuals involved have access to information from a wide variety of



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 140
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities 4 Designing a Common Command and Information Infrastructure This chapter begins by articulating the concept of a common command and information infrastructure for the naval forces, the Naval Command and Information Infrastructure (NCII). In particular, Section 4.1 notes the general attributes that the NCII should possess, including adaptability in the face of changing needs and new technologies, and the functional capabilities it should provide to support users. The NCII supports all echelons—strategic, operational, and tactical—with a uniform architecture that uses commercial network protocols, a concept that, for tactical networks, runs contrary to the current situation. Section 4.2 develops this important point, and it is further elaborated on in Appendix E. Since an architecture is key to realization of the NCII, Section 4.3 discusses the products and processes the Department of Defense (DOD) and the Department of the Navy currently use for developing architectures and comments on their suitability for developing an NCII architecture. Section 4.4 gives the committee’s recommendations based on the material presented in the preceding three sections. 4.1 THE NAVAL COMMAND AND INFORMATION INFRASTRUCTURE CONCEPT 4.1.1 Definition and Properties The broad and rapid exchange of information and the ready assimilation and use of this information are at the heart of network-centric operations (NCO). In NCO, the individuals involved have access to information from a wide variety of

OCR for page 140
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities sources and can operate in an effective, coordinated manner by exchanging information, even if the force elements are widely dispersed. As a consequence, decision making should be more informed than is now the case, collaborative planning among dispersed elements should be more timely and complete, and distributed engagements involving sensors, fire control authority, and weapons at separate locations should be more readily executable. Underlying this exchange and use of information is the Naval Command and Information Infrastructure, so named to indicate an infrastructure that supports not just the manipulation of information but also the actual functions of command. Such an infrastructure should possess a number of attributes: It should integrate and support operations at all levels of command; It should be responsive and assured, providing a continuously available, secure, high-integrity resource to support all information needs; It should facilitate information management by offering consistent, tailored operational information to specified recipients; It should be dynamic and self-organizing, automatically healing breaches and forming and automatically maintaining high-priority, low-latency broadcast or normal communication channels; It should be independent of location, providing great operational flexibility in the geographical positioning of component units; and It should be easily scaled and evolved, adaptable in size to meet changing needs, and capable of being modernized easily through the use of common, open interface standards and functionally modular design. The NCII (see Figure 1.6 in Chapter 1) comprises the communication and computing assets necessary to accomplish two things: (1) effect the exchange of information among information repositories, sensors, command elements, forces and weapons, and logistic and support elements and (2) allow this information to be used for both human decision making and automated processes pertaining to command and execution.1 The communications and computing components embedded with sensors, platforms, weapons, and support systems are not considered part of the NCII, but the effective operation of the NCII requires that their interfaces to the NCII satisfy standards established in the overall NCII design. Information repositories are part of the NCII if they are naval assets directly supporting command, but other naval information sources that may be called upon (e.g., personnel databases) are not part of it, although their inter- 1   The word “infrastructure” as used in this report includes both the underlying communications base and the common support applications that ride atop the base; specific mission applications are not included.

OCR for page 140
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities faces to the NCII must be compatible.2 Joint and intelligence information sources are regarded similarly. An information infrastructure like the NCII has natural analogs at the operational and strategic levels of warfare (e.g., the Global Command and Control System). The infrastructure also applies at the tactical level since it refers to general means for manipulating and transporting information, although one needs to define its scope at the tactical level carefully. Two cases in point illustrate the issue—tactical digital information links (TADILs) and the cooperative engagement capability (CEC). Because TADILs represent a general information exchange capability, they would fall within the scope of the NCII. The issue here is that the current TADIL implementations would not comply with the architectural standards that will probably be chosen for the NCII (e.g., Internet Protocol (IP) networks). However, over time (see Section 4.2 below), the TADILs could migrate into compliance. The CEC could be a different matter. It is a specialized implementation necessary to meet particularly demanding performance requirements. It is not clear, at least at this time, if the general standards chosen for the NCII would satisfy CEC performance requirements. If they do not, then the CEC would remain outside the NCII, but its interface to the NCII would have to satisfy standards established in the overall NCII design. 4.1.2 Information Use and Design Considerations The next step in developing the NCII is to characterize more precisely the functions it will perform. That, in turn, requires that the concept for information use be considered. 4.1.2.1 Internet Paradigm Network-centric operations embody the idea of rapid, ready, and flexible access to information, with the Internet in some sense serving as a model or paradigm. The Internet, as commonly referred to in popular discussion today, has two components: (1) a robust, underlying networked communications base and (2) the applications that make use of the communications base to provide information to a widely dispersed user population. The communications base derives from the ARPANET begun in the early 1960s, while the applications have appeared mostly within the last decade. The ease with which these applications have been able to make use of the underlying communications base has been a critical factor in the rapid growth of the Internet and the effect of the applications on society. The point for NCII design is to view the infrastructure as having two layers, a supporting resource base (e.g., communication) and 2   The close association of logistics with command and control means, however, that the logistics databases should be part of the NCII.

OCR for page 140
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities applications, which should be easily able to make use of the supporting resource base. The Internet model has two aspects, top-down and bottom-up, both of them important. On the one hand, some top-down principles and standards are necessary so the applications can easily use the communications base and so users can interact with applications. On the other hand, the applications were developed from the bottom up, i.e., by a diverse developer population. This diversity means there is a broad base for innovation, which has contributed greatly to the widespread popularity and utility of the Internet. The point for the NCII is that it should use a framework of standards that would permit its applications to come from a diverse set of sources. Further insight can be gained by focusing on the user. The Internet today (and even more so in the future) allows access to an “information marketplace.” Users’ needs are not satisfied with a predefined set of information; rather, they seek widely for the information they need. This behavior has a direct analogy in military operations in the current and anticipated future world environments. In the more prescribed scenarios of the Cold War, one could define the information requirements quite well, but now, uncertainty as to the type and location of future military operations precludes that. Furthermore, different operators may vary in their approach to a situation and hence in their information needs. Certain information requirements can be predicted—e.g., a unit will obviously want to know when it is under attack—but overall, detailed information requirements cannot be predicted in advance and will vary from user to user. From this it follows that the NCII should provide users ready and flexible access to information. While the NCII should allow widespread dissemination of information, it must also be able to accommodate the need of commanders for some degree of control over dissemination (e.g., for security purposes and bandwidth management). Furthermore, this information dissemination enables greater decentralization of command, but at the same time it allows for the centralized collection of information and hence for greater centralization of authority. There is no single appropriate point on this centralization-decentralization spectrum; it will depend on the nature of the military operation. The NCII must able to support these varying modes of command. Finally, it is critical to recognize that the manner in which information is used in the NCII will change continually as operational concepts are refined and new technologies introduced. This is the lesson of personal and business use of information technology: One cannot fully anticipate all the myriad ways that it can be used. Rather, one has to work with the technology to explore its uses, and these uses will suggest new technologies to be explored, which will lead to further new uses. Thus, the NCII must be designed to allow this continual evolution in information use and the introduction of new technology.

OCR for page 140
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities 4.1.2.2 Decision Focus The ultimate end use of information in military operations is to support decision making. Since the final measure of any information system is the quality and timeliness of the decisions reached, the decisions should be central in assessing the functionality provided by the NCII. Figure 4.1 is a highly simplified schematic of the information flow in the decision-making process at all levels of command. It makes clear that there are two aspects to the information support of decisions. First is the information gathering and generation stage, to prepare for and support making a decision. As discussed above, decision makers (or their staffs) should be able to easily find information and draw it to themselves. Second is the command dissemination stage—that is, the decision itself is information that must be conveyed to appropriate elements. The NCII applications should be specifically designed to support this decision-making process. Not shown in Figure 4.1 but important to realize are the different time scales that can be involved. Generally speaking, there are two such scales. At the operational-strategic time scale, information is gathered, decisions made, and results disseminated in a time span ranging from minutes to hours (or even days). In the tactical time scale, the same process takes place in a matter of seconds or fractions thereof. In highly compressed tactical situations the decision-making function can be short-circuited by passing the information directly from the sensors to the weapons or possibly with automated processes replacing human decision making. Similarly, very rapid iterations in the decision process can be made in response to the changing tactical situation. FIGURE 4.1 Information flow in decision making.

OCR for page 140
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities 4.1.2.3 Summary The NCII must provide a set of functional capabilities, i.e., a set of system functions to support the user. These capabilities would be partitioned between applications and a supporting resource base. The application layer would contain specific functional capabilities to support the decision-making process. The supporting resource base provides more generic functional capabilities (e.g., communications), although generally speaking, these capabilities support decision making, too. Specification of functional capabilities is not sufficient for designing an NCII, however. For example, the NCII must be easily configured to meet specific mission needs. This requirement is not satisfied by a functional capability; rather, it refers to a property of the system as a whole and is achieved by applying certain design principles to the overall system. Thus, both the functional capabilities and the system properties must be specified. There are thus three general classes of requirements for the NCII: Functional capabilities that directly support decision making both in the information gathering and generation stage and in the command dissemination stage, Functional capabilities for the supporting resource base (e.g., communications), and Design practices to achieve system properties (e.g., configurability). 4.1.3 Functional Architecture The functional architecture shown in Figure 4.2 describes the capabilities that the NCII must provide and shows the interrelationships among these functions. Figure 4.2 follows from Figure 4.1 by inserting specific functions (e.g., collection management) to support the decision-making process, recognizing that these functions ride on top of a supporting resource base. The four functions to the left of the decision box in Figure 4.2 enable information gathering and generation, and the single function to the right of the box supports command dissemination. The functions for the supporting resource base may be described as follows: Communications and networking. These are the basic services that provide the communication links and form networks from them. Some communications could be point to point and not necessarily part of a network. Information assurance. This function protects the information content from unauthorized disclosure or modification and ensures its delivery to intended users. Protection against both malicious threats and system failure would be considered in realizing this function.

OCR for page 140
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities FIGURE 4.2 NCII functional architecture for information gathering and generation and command dissemination. System resource management. This function furnishes services so that applications use the supporting resource base in an efficient, coordinated manner, in keeping with established priorities. Thus, the function would include services to manage and allocate bandwidth and to provide end-to-end quality of service. There is more to the supporting resource base than the three functions given. There are also processing and storage functions. However, for the scope of this report, the three functions described were considered to be the ones requiring the most emphasis and assessment. The functions supporting information gathering and generation and command dissemination may be described as follows: Collection management. This function determines the tasking of sensors to collect data. It should task the sensors based on an integrated view of the sensor assets available and should support cross-cueing between sensors.3 Information exploitation and integration. This function extracts basic information from the initial input data and further refines that output by correlating, fusing, and aggregating it. Information request and dissemination management. This function provides information based on user-specified requests for a given type of informa- 3   Data input parallels collection management by drawing data from stored databases. Standard database retrieval methods are involved. Given the scope of this study, this function does not receive further treatment.

OCR for page 140
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities tion. Its operation is transparent in that users do not have to know the details of where the information is located. This function will also provide information to users based on the directions of any other authorized party. Information presentation and decision support. Information presentation is the graphical display of information to users. Decision support is a set of automated tools that allows users to manipulate information for the purposes of making a decision. Execution management. This function supports delivery of decisions to the intended recipients and allows for dynamic adaptation of those decisions in the light of rapidly changing events. It could have been included under decision support but was believed to be important enough to be singled out. The logical flow among the functions is easily seen. For example, if a user wanted a certain type of information, he or she would go to a particular display (information presentation) or request it in some generic manner (information request and dissemination management). Either of these functions would then draw on the base of exploited and integrated information, and, if necessary, sensors could be tasked to gather further data. The set of functions given here seems complete, apart from the omission of the processing and storage functions noted above. The next step in development would be to specify the subfunctions or services that make up each of these functions and then to implement them in software or hardware. Particular attention should be paid to defining the interfaces to each of these functions and subfunctions so that they can interact appropriately. There are existing programs for implementing some of the functionality, although not generally within the context of the integrated view expressed in Figure 4.2. Chapter 6 discusses the status of implementing these functions. 4.1.4 System Properties As discussed in Section 4.1.2, specifying the NCII also requires giving the system properties that it must satisfy. Such a list could be made quite long, since there are many desirable properties that a system should have, but here the list is held to just those few properties deemed most important (Table 4.1). Information assurance appears both as a system property and, above, as a functional capability. It is a system property since it is achieved only when all components of the system are secure and protected. But it is so critical in establishing networks, given the vulnerability the networks could introduce, that it is also explicitly singled out in the supporting resource base. The other properties listed in Table 4.1 are also critical. The lesson of modern information technology use, as demonstrated for example by the Internet, is that new and useful applications are continually arising. The situation should be no different in support of military operations, so flexibility to accommodate

OCR for page 140
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities TABLE 4.1 Important System Properties Required in the Naval Command and Information Infrastructure System Property Desired Attributes Information assurance: assures continued availability of service despite failure of components and attack The infrastructure should withstand multiple dependent and independent failures, including loss from physical attack. The infrastructure should continue in the face of successful attacks to provide service for the most critical needs. It should be able to isolate the attacker, reallocate resources, repair the damage, and recover. Backup modes of operation should be available. Flexibility: accommodates new applications The time required to test or widely deploy a new application should be short and the effort very little. This will encourage creative thinking and the emergence of applications based on user ideas. In particular, the system should include a “sandbox” for testing new applications. Modular system design: accommodates new technology and software upgrades Hardware and software will continuously evolve. New applications may require new or expanded software functionality. It is essential that the architecture allow independent upgrades of software modules. Fast and easy configuration: meets tailored mission needs It should be possible to generate system software and hardware configurations using system configuration tools. These tools should be capable of automatically generating configuration modules and simulating and testing the composed configuration, and a variety of graphical interfaces should be provided for different users requiring different levels of detail. new applications is needed. The pace of information technology change is rapid, so it must be possible to incorporate relevant new technologies with minimum cost and time, which calls for modular system design. Finally, the configuration of deployed forces cannot be specified in advance, especially given the variability of military operations in the current and anticipated world environments, so configuration has to be fast and easy to meet tailored mission needs. These properties require certain design principles and practices and can also be supported by technological innovations. Realizing the system properties should be one of the key considerations in developing the system architecture for the NCII.

OCR for page 140
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities 4.1.5 Relationship to Other Information Infrastructures Several information infrastructures are being discussed currently in DOD-wide and Service contexts. This section relates the NCII to them. The defense information infrastructure (DII) is quite extensive, being regarded as “… the sum of all information management assets [supporting warfighters] owned by each of the Office of the Secretary of Defense (OSD) Principal Staff Assistants (PSAs), Joint Chiefs of Staff, Combatant Commanders, the individual Military Services, and Defense Agencies.”4 The NCII and the DII are not mutually inconsistent concepts. However, the DII is much broader in scope and has a nearer-term focus (the planning horizon in its master plan is typically 2 years). The Department of the Navy’s Chief Information Officer (CIO) has led development of the concept of an information technology infrastructure (ITI).5 The ITI articulates the network connectivity and services needed to support all naval systems that produce, use, or exchange information electronically. In one sense it is broader than the NCII since it also applies to business operations. It is narrower in the sense that it focuses on network connectivity and services, which are in the supporting resource base in the NCII definition. The NCII also includes the functions supporting information gathering and generation and command dissemination (see Figure 4.2). The NCII and ITI are not inconsistent; rather, they have different emphases. In fact, one could imagine the ITI evolving to put more emphasis on upper-layer functions as does the NCII. The Defense Science Board has articulated the integrated information infrastructure (III) concept.6 In general terms, it comprises information transport, distributed computing resources, and information services (service agents and application support agents). The NCII and the III are quite similar in spirit, although the NCII goes into more functional detail in the information services (i.e., the upper layer in Figure 4.2). The concept of the battlespace infosphere (BI) developed by the Air Force Scientific Advisory Board7 is not a full infrastructure, but rather a combat information management system. Thus, it is narrower in scope than the NCII 4   Defense Information Systems Agency. 1998. Defense Information Infrastructure Master Plan, Version 7.0. Department of Defense, Washington, D.C., March 13. 5   Information Technology Infrastructure Integrated Product Team. 1999. Information Technology Infrastructure Architecture (ITIA), Version 1.0 Proposed, 3 volumes (draft). Chief Information Officer, Department of the Navy, Washington, D.C., March 16. 6   Defense Science Board Summer Task Force. 1998. Joint Operations Superiority in the 21st Century: Integrating Capabilities Underwriting Joint Vision 2010 and Beyond. Office of the Under Secretary of Defense for Acquisition and Technology, Washington, D.C., October. 7   United States Air Force Scientific Advisory Board. 1998. Report on Information Management to Support the Warrior, SAB-TR-98-02. Department of the Air Force, Washington, D.C.

OCR for page 140
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities but develops the information management concepts in much more detail than does the NCII (or any of the other information infrastructures noted above). A major point follows from the above discussion. More important than the differences in emphasis among the infrastructures is the fact that several different organizations looking at the problem from different perspectives have all come up with the need for articulating an information infrastructure to support warfighting operations across all echelons.8 The point for the naval services is to articulate in their planning for network-centric operations a concept such as the NCII. The IT-21 strategy (discussed in Chapter 6) is an excellent start in this regard, although it is not complete. It focuses on connectivity, with less explicit recognition of the upper-layer services depicted in Figure 4.2. A second important point, made in most of the information infrastructure discussions, is the need for jointness. There are two aspects to this. First, the information infrastructures do not operate in isolation. Rather, information should be shared readily across Service boundaries, as well as across the military-intelligence boundaries. Second, the different information infrastructures should not be developed separately. Given the common need of the Services and the joint community for these infrastructures, there should be cooperative efforts to develop them. One opportunity for such collaboration has just arisen. The Air Force in its expeditionary force experiments (EFXs) is planning in 2000 to begin exploration and development of the battlespace infosphere and is seeking joint participation.9 Naval participation, and in particular examination of the NCII concept, would seem to be highly beneficial to both the naval services and the Air Force. By participating, the naval services could benefit from the momentum and significant funding already inherent in the EFX series, and the joint nature of both the NCII and BI could be explored. A third and final major point to recognize is that all the information infrastructures contain shared and common-use assets. For example, long-haul communications used in the NCII will be based in part on SATCOM assets shared with the other Services and joint community. Software in the NCII—e.g., to support the information gathering and generation functions shown in the upper part of Figure 4.2—will be developed in part for use across the Services and joint community. Some of this software might be unique to naval needs (e.g., 8   In addition to the information infrastructures noted in the text, mention should also be made of the newly emerging idea of the global information grid (GIG) being articulated by OASD (C3I) and the Joint Staff. Development of the GIG is currently focusing on policy matters, but it is likely that when a technical definition emerges it will in general be consistent with the NCII and the other infrastructures noted here. In fact, it could possibly benefit from some of the concepts being developed for the NCII. 9   The BI has been renamed the joint BI (JBI), and the EFXs are now called joint EFXs (JEFXs).

OCR for page 140
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities tions, in contrast to the perspective taken in the C4ISR Architecture Framework. The systems architecture view given in the framework focuses on the physical implementation of systems, as indicated by its definition of systems architecture as “a description, including graphics, of systems and interconnections” and by the fact that the only essential (required) architecture product is the system interface description. This distinction is explicitly noted in the following excerpt from the SPAWAR Naval C4ISR Architecture Primer:18 … in transitioning from an operational to a system architecture the Navy approach and the CISA approach are different [CISA is the OASD(C3I) organization that developed the C4ISR Architecture Framework]. Essentially, the Navy’s approach includes two phases: a functional analysis and a physical analysis. The CISA approach jumps immediately to the physical analysis …. The Navy believes that jumping immediately to the physical analysis is appropriate for “As-Is” architectures, but developing “To-Be” architectures requires a more thorough understanding of systems functions, and therefore the Navy’s approach precedes the physical analysis by a functional analysis. As technology and operational requirements change, the Navy approach would make operational, systems, and technical architectures less costly to implement. In short, articulation of the system functions is a critical intermediate step in moving from the operational view to the physical implementation of the C4ISR system. The Navy C4ISR Technical Architecture, currently released as Version 2.0, pertains to the inter-platform and intra-platform C4ISR interfaces necessary to support Navy missions and their subordinate functionality and performance parameters. It also pertains to C4ISR interfaces with other Navy systems, such as weapons, sensors, and combat support. This technical architecture contains a subset of the standards in the JTA and additional standards unique to Navy missions and noncompeting with the JTA. It is patterned after the JTA and as such is largely a listing of standards. It divides standards into the same categories as the JTA (see Section 4.3.1.2 for the five categories), except that it also adds the category “intelligence, surveillance, and reconnaissance.” In addition, it contains a set of appendixes listing the standards unique to Navy mission areas. A separately published appendix, “Migration Strategy,” provides information to aid in the migration from current standards to target standards. The last release of this volume, Version 1.5 dated July 16, 1998, refers to target standards for the year 2000. 18   Deputy Chief Engineer for Architecture and Standards. 1997. Naval C4ISR Architecture Primer, final draft, SPAWAR 051-2. Space and Electronic Warfare Systems Command, Washington, D.C., January 17, pp. 4-18.

OCR for page 140
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities 4.3.2 Application to the NCII When the various DOD and Navy architectural products and processes described above are related to the development of an NCII architecture, several shortcomings in the current products and processes are evident. 4.3.2.1 Operational and Systems Architectures The discussion in Section 4.1.2 emphasizes that information needs cannot be regarded as fixed. Users will vary in their needs, will evolve with respect to the type of information they want as they explore and use what is available, and will want to tailor the way information is provided and presented to them. Furthermore, the ways in which new information technology can be applied are often not immediately apparent. One has to work with new technologies to explore their uses, and these uses will suggest additional technologies to be explored, which will lead to further new uses. This continual interplay between the exploration of technology and the evolution of operational concepts will lead to ongoing changes in the way information is used. All this requires a rapid, iterative process of technology exploration and refinement of operational concepts (a theme developed in detail in Chapter 2). This requirement for flexibility and rapid iteration does not seem well supported by the detailed methodology of the C4ISR Architecture Framework. Three points are particularly relevant: The number and detailed extent of the C4ISR architecture products means they take significant time to develop. This is inconsistent with the rapid iteration necessary in introducing technology and refining operational concepts. The rapid iterative process requires the close and frequent interaction of system users and developers. If the operational architecture is developed through to its end and the systems architecture is then begun, which seems to be implied by the C4ISR Architecture Framework methodology, then this interaction cannot take place. Articulation of the system functions is a key intermediate step in moving between operational concept and system realization. As noted in the discussion of systems architectures above, system functions do not play a prominent role in the C4ISR Architecture Framework methodology. The C4ISR Architecture Framework would seem to have utility in the development of well-understood systems for which the requirements can be laid out in detail in advance of the development of the system. To accommodate the more flexible, iterative process necessary for constructing the NCII, the following significant changes to the framework methodology appear necessary:

OCR for page 140
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities New high-level products must be developed to describe the operational and systems architectures, intermediate in detail between the current operational concepts given on a single chart and the detailed tabular information now produced in operational and systems architectures. Since such products could be modified relatively quickly, they would support a rapid iterative process and allow the close interaction of operational and systems personnel.19 An architectural product must be established to indicate the concept of operations for using information. The current examples of operational architecture all relate to how information supports traditional warfighting tasks, which is obviously required. But there is also a need to consider how the information is treated. For example, is it obtained by push or pull? How does the commander want to promote or limit its distribution? Critical factors such as these need to be recorded for systems to be developed and used properly. For best use, these would be high-level (five-page summary) products. The best course might be to have the operational architecture provide only a general template for this type, with the particular details inserted by individual commanders and their staffs. Greater prominence must be assigned to the role of system functions in the system architecture products. As noted, the system functions are central in the relationship between concepts of operation and system realization. Such a system architecture product could be made essential (i.e., required in all system architecture developments). In addition, an intermediate level of detail would serve the flexibility needed in a rapid, iterative development process. 4.3.2.2 Technical Architecture A technical architecture, as envisioned in the C4ISR Architecture Framework, serves important purposes: It promotes the use of commercial products, which can mean lower costs and faster technology refresh cycles; it leads to open-architecture designs, which facilitate interoperability; and it aids modular design practices, which can make technology upgrades easier. Standards typically change on longer time scales than do the individual technologies, so developing architecture products that can be modified quickly is less critical for technical architectures. However, an important concern in technical architecture products is that the set of required standards be kept as small as possible, for two different reasons: to avoid unduly constraining system developers by mandating standardization where it is unnecessary or premature to do so, and to limit the set of choices for 19   Development of an automated tool to facilitate construction of operational architectures is discussed in Chapter 6, Section 6.2.7.3.

OCR for page 140
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities a given standards area so that different developers do not unnecessarily choose different standards, which can adversely affect interoperability. The JTA claims to be a minimal set of standards, and both the Department of the Navy ITSG and the SPAWAR Technical Architecture claim to further refine the standards selection to suit the Navy’s needs. However, the limited analysis possible for this report did not allow determining if these three technical architectures were appropriately minimal. Note that most of the standards in the JTA, or refinements of the JTA for naval purposes, would be of two types: commercial standards (e.g., for network services) or DOD-wide standards (e.g., for specific application domains such as intelligence or logistics). Few, if any, of the standards would be naval unique. Thus, the naval offices responsible for determining the standards would, in general, have to choose from broader sets of standards and not develop their own standards. Relatedly, these offices should interact with the broader communities developing the standards to ensure that naval needs are met. 4.3.2.3 Beyond Current Standards-based Architectures The systems architectures discussed thus far above would all be based on the interfaces, services, and accompanying standards specified in the technical architectures (JTA, ITSG, and the Navy C4ISR Technical Architecture). That is the current state of practice, and much can be said for it. However, there still are shortcomings. For example, given the pace at which technology is advancing, it is not possible to impose common standards on a wide community (consider, as a possible extreme, a community of U.S. forces and coalition forces). Thus, limitations could occur when elements of this wide community need to interoperate with one another. In addition, even if common standards from the JTA (or a similar source) are used, the definitional consistency of the data that are exchanged must also be considered. Again, for practical reasons, it is not possible to impose common data definitions across wide communities. Furthermore, account must be taken of the fact that excessive imposition of standards will limit innovation. Thus, one needs to look for advances in technology or in design practice that will lead beyond the current technical architectures to address problems such as those just noted. The JTA and similar documents do have sections on emerging standards and are thus anticipating the future to a limited degree. But it is not the function of these technical architectures to be a vehicle for tracking and promoting revolutionary, but potentially highly beneficial, technologies. Such technologies are now being pursued, including the following: Semantic interoperability. Research in this area is aimed at achieving means for common semantic understanding across components developed with different data representations. One example of research in this area was carried

OCR for page 140
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities FIGURE 4.4 Schematic of the emerging Control of Agent-based Systems grid architecture, which minimizes integration effort to connect to the grid by adapting the connection mechanisms instead of the client components. SOURCE: Hendler, James, “Control of Agent-based Systems Technical Overview,” a briefing presented to the System Architecture Panel on April 15, 1999, Information Systems Office, DARPA, Arlington, Va. Acronyms: ACL, agent communication language; API, application program(ming) interface; CORBA, common object request broker architecture; OAA, over-the-air activation signal; RMI, remote method invocation; XML, Extensible Markup Language. out in conjunction with the Defense Advanced Research Projects Agency (DARPA) Dynamic Multiuser Information Fusion (DMIF) program and is now being continued under the Air Force Office of Scientific Research (AFOSR).20 Agents. The DARPA Control of Agent-Based Systems (CoABS) program is exploring the use of agents as an interoperability mechanism. Interfaces might be more flexibly defined if the agents could negotiate interactions between system components. Currently under development in the program is a metaframework or grid (see Figure 4.4) that will allow agents operating under different agent communities or interagent languages to communicate. In addition, an effort is about to begin to establish a new agent language intended to 20   Krikeles, B., and T. Libby. 1999. Achieving Information Superiority: Interoperable Components and Battlespace Representation. ALPHATECH, Inc., Burlington, Mass., March 27.

OCR for page 140
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities progress well beyond current Web languages (HTML, XML) that will provide readable (interoperable) semantics, given a developed ontology.21 Publishing internal properties. In this instance the components of a system would make known to the broader system certain aspects of their internal composition. This would permit greater flexibility and tailoring in establishing interfaces with those components. One example of this general idea is the terminal access packet discussed in Chapter 6 (Section 6.2.3.3). While such work is ongoing in the research community, it needs greater recognition and support at senior Navy Department and DOD levels. Officials at those levels should not believe that the DOD and naval technical architectures as they now exist provide a complete solution to the technology specification for architectures. The capabilities envisioned for the NCII cannot be fully realized with current technical architectures. The necessary flexibility and adaptability will require advances in architecture-related technologies such as those noted above. 4.3.2.4 Organizational Responsibilities According to the discussions above, three naval organizations are actively involved in architecture and thus could be involved in development of an NCII architecture—the Department of the Navy CIO, Department of the Navy CHENG, and SPAWAR.22 It is thus important to understand what might be the boundaries of responsibility that each organization could have for the NCII architecture. The Department of the Navy CIO would appear to have a significant responsibility given the enterprise-infrastructure architect role assigned it by the Clinger-Cohen legislation. However, the Department of the Navy CHENG would also seem to have significant responsibility according to its charter. And SPAWAR has traditionally been involved with the development of C4ISR architectures. Perhaps the Department of the Navy CIO should be responsible for the general infrastructure aspects, while the Department of the Navy CHENG should oversee the C4ISR specific aspects and interfaces to weapons and other systems, and SPAWAR should develop the detailed C4ISR aspects. The responsibilities of the Department of the Navy CIO and Department of the Navy CHENG would appear to lie in the systems and technical architecture 21   Note is also made of the Foundation for Intelligent Physical Agents, which is trying to promote open specification of agent systems to maximize their interoperability. Information is available online at <www.fipa.org>. 22   The combat systems that NAVSEA and NAVAIR develop are outside the scope of the NCII, but since they must interface with the NCII, broader considerations would include NAVSEA and NAVAIR.

OCR for page 140
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities areas. Of the three organizations, SPAWAR is the only one that has developed operational architectures, although these are primarily as-is architectures. Organizations from the doctrine and experimentation communities might be appropriate for developing the future operational architectures. Organizational responsibility for the NCII architecture must be assigned before the architecture can be properly developed and implemented. The matter of organizational responsibility for network-centric operations as a whole, including NCII development and operation, is discussed in detail in Chapter 7. One suggested scheme for assigning responsibilities for the NCII in keeping with the discussion above and consistent with the material in Chapter 7, could be as follows: Resource allocation and requirements sponsor: OPNAV N6; Operational architecture: Commander, Operations Information and Space Command, with the support of OPNAV N6; Policy and standards: Department of the Navy Chief Information Officer; Systems and technical architectures (including enforcement): Department of the Navy Chief Engineer; Acquisition and procurement: Program management as designated by the ASN (RDA) (e.g., the PEO-IT); and Operational management: Commander, Operations Information and Space Command. Included in this list is a new position introduced and recommended in Chapter 7—the Commander, Operations Information and Space Command. This individual would be a functional type commander analogous to existing type commanders (e.g., for air assets) and would be concerned with the information assets of the fleet just as the other type commanders are concerned with the assets in their areas. SPAWAR, NAVSEA, and NAVAIR would also figure in the assignment of responsibilities by providing support to the areas listed.23 4.4 RECOMMENDATIONS The recommendations presented here are organized according to the three main topics discussed above: establishment of the NCII, tactical networks, and architecture development. 23   Chapter 7 also recommends double-hatting a Navy SYSCOM commander as a deputy to the ASN (RDA) for integration of network-centric operations. This individual would coordinate in the acquisition and procurement decisions.

OCR for page 140
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities 4.4.1 Establishment of the NCII The NCII offers a comprehensive, unifying concept. In broad terms, the committee recommends that the naval services adopt and apply the NCII as the overarching concept for providing information support to network-centric operations. In more specific terms, it makes three recommendations: Recommendation: The Department of the Navy should develop and enforce a uniform NCII architecture across the strategic, operational, and tactical levels of naval forces. This means that, for all levels, (1) the same set of functions will apply (as defined in Figure 4.2),24 (2) interfaces and standards associated with these functions will be the same, and (3) consistent definitions will be used for the data exchanged between the functions. Such an architecture would integrate the system capabilities and facilitate the interoperation of forces. As such, it would promote the widespread and flexible exchange of information necessary for network-centric operations. Recommendation: The Department of the Navy should give an organization the responsibility and adequate resources for (1) establishing a comprehensive view of capabilities and programs necessary to implement the NCII and (2) seeing that these capabilities are realized. During its information-gathering efforts, the study committee found numerous naval and joint organizations that were able to provide valuable information on various components of information infrastructures. Yet the committee was continually struck by the fact that no one office or organization had a comprehensive view of the capabilities and programs that would constitute an infrastructure such as the NCII. No organization was found, for example, that had an end-to-end systems view of information-handling capabilities, such as that shown in Figure 4.2.25 Furthermore, many offices provided valuable information on programs relating to individual functional capabilities, but none had an overview of a full set of relevant programs. Effective realization of the NCII requires that some organization have an overview of its requirements and the programs satisfying those requirements. 24   The tactical domain will, in addition, have its own unique functions that are particular to warfighting mission areas. These are considered in Chapter 3. 25   There are excellent end-to-end views of communications and networking capabilities, but as Figure 4.2 makes clear, there is also a significant information-handling component that rides on top of the communications and networking.

OCR for page 140
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities The set of programs is large and comes from diverse sources (Chapter 6 briefly discusses some of these programs). The organization would not control the programs as does a traditional program manager. Indeed, in modern large-scale information systems, no one controls all the pieces; rather, the managing organization understands what pieces are available and how they fit together. Accordingly, the desired organization would identify the relevant developmental activities (both government and commercial) that could support the infrastructure, track their evolution and progress, and indicate which should be applied in implementing the infrastructure. Furthermore, this organization would identify requirements that are not being met through the activities and establish priorities for meeting these shortfalls. Gaining such an overview is a substantial undertaking, so this organization would require significant resources in terms of both staff and funds. Recommendation: The NCII should be developed in collaboration with the other Services, the joint community, and National agencies to promote interoperability and build on each other’s efforts. The NCII is presented here as a naval concept, in keeping with the study’s purpose, which is to examine naval network-centric operations; nonetheless, much of what is discussed is of interest and use to joint and other Service operations. In fact, the other Services are developing analogous concepts, and many of the supporting programs come from the joint community (e.g., DARPA and DISA), as well as the intelligence community. Thus, to promote interoperability and avoid unnecessary duplication, the naval organization responsible for implementing the NCII should collaborate with the broader community. As noted in Section 4.1.5, one potentially valuable, immediate opportunity would be participation with the Air Force in its expeditionary force experiments. 4.4.2 Tactical Networks The committee makes two recommendations pertaining to a transition strategy in particular to ensure that tactical information networks conform to the NCII architecture. Recommendation: With few, if any, exceptions, new tactical information networks should conform strictly to the NCII goal architecture and should use appropriate gateways, firewalls, and encryption devices to ensure high quality of service. The term “strictly” is used because at any moment there may be within the NCII legacy systems that do not conform to the goal architecture but that have

OCR for page 140
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities been grandfathered into an interim standard. New systems must not be allowed to perpetuate the characteristics of the nonconforming systems. Although the committee recognizes that engineering some difficult future communications links may lead to new waveforms and antenna control schemes for transport, it thinks it may be possible and desirable to implement a standard IP bearer in most or all network terminals and to separate that protocol from message content. In some cases the Navy or the DOD has already thought seriously about this possibility. Summarizing the conclusions of Appendix E on this matter, the committee recommends as follows: Recommendation: Terminals of the Joint Tactical Information Distribution System (JTIDS) and common data link (CDL) families should be modified to use NCII standard protocols. The pros and cons of so modifying the CEC data distribution system should be studied further. In addition, a further recommendation pertains to necessary research and development. Recommendation: The DOD, including the Navy, should sponsor a vigorous research and development program aimed at improving the performance of wireless information networks that can self-organize with high assurance despite limited and highly variable connectivity between pairs of nodes and despite likely loss or degradation of some nodes in the network. 4.4.3 Architecture Development Current architectural guidance and development processes will have to be significantly modified and enhanced to support the development of the NCII. To that end, the committee recommends the following: Recommendation: The Department of the Navy should work with the ASD (C3I) and the other Services to make the operational and systems architecture products specified in the C4ISR Architecture Framework suitable for the flexible and rapidly evolving information support that the NCII must provide. The discussion in Section 4.3.2.1 indicates some of the additions and changes to current architecture products that should be made. Recommendation: The Department of the Navy should ensure that the naval technical architectures are minimal necessary sets of required standards. Recommendation: The Department of the Navy should support efforts to advance beyond standards-based architectures (such as the current JTA).

OCR for page 140
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities More advanced architectural concepts are needed to realize the flexible, rapidly configurable information support envisioned with the NCII. Examples of research in this area are noted above in Section 4.3.2.3. The important point is that senior Navy and DOD officials recognize and support the need for such research. Recommendation: The Department of the Navy, in developing an NCII architecture, should clarify the architectural responsibilities across the various naval offices currently involved in architecture development. Responsibilities must be clearly delineated. A suggested assignment of responsibilities is given in Section 4.3.2.4.