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 64
--> 2 Interoperability 2.1 What is Interoperability And Why is it Important? The full realization of Joint Vision 20101 and the revolution in military affairs, discussed in Chapter 1, is predicated on a concept of information superiority enabled and supported by a network of C4I systems—one whose constituent elements interoperate and cooperate to support the entire warfighting hierarchy, in the context of joint and coalition operations. Interoperability of C4I systems is a key enabler of the overarching operational goal of force integration—the fusing of the services and coalition partners into a unified military force that achieves high military effectiveness, exploiting and coordinating the individual force capabilities. Achievement of a high level of interoperability requires a commensurate level of effort and resource prioritization throughout DOD. Today, DOD is just at the beginning of refining and even establishing the processes and organizations to respond to future needs for C4I interoperability. 2.1.1 What is Interoperability? Interoperability is a broad and complex subject rather than a binary attribute of systems. C4I interoperability is a key enabler for the conduct 1. Chairman of the Joint Chiefs of Staff. 1996. Joint Vision 2010, Joint Chiefs of Staff, Washington, D.C.
OCR for page 65
--> of effective, collaborative, multi-service military operations across a wide spectrum of scenarios, and successful conduct of operations is the ultimate test of whether an adequate degree of interoperability is being achieved. Joint Chiefs of Staff Publication 1-02 defines interoperability at both the technical and operational level (Box 2.1).2 Operational interoperability addresses support to military operations and, as such, goes beyond systems to include people and procedures, interacting on an end-to-end basis. Implementation of operational interoperability implies not only the traditional approach of using standards but also enabling and assuring activities such as testing and certification, configuration and version management, and training. These definitions of operational interoperability encompass the full spectrum of military operations, including intra-service/agency, joint (inter-service/agency), and ad hoc and formal multinational alliances. Interoperability at the technical level (see Box 2.1) is essential to achieving operational interoperability. An issue that arises between systems rather than between organizations, technical interoperability must be considered in a variety of contexts and scopes, even for a single mission. Consider the theater missile defense mission, which is likely to require that data be: Exchanged among elements of a weapon system. For example, the Patriot air defense system uses a defined message format and data link to exchange information within batteries and between batteries to share target information and coordinate defensive actions. Exchanged between weapons systems of a single organization or service . For example, the Theater High Altitude Area Defense system (under development) will provide theater ballistic missile tracks to Patriot systems. Exchanged between weapons systems of different services. For example, a Navy AEGIS radar may report tracks to an Army Patriot radar. Shared and "pooled" at the joint task force command and control systems level (or higher) in order to achieve synergy and added value . For example, Patriot, AEGIS, and Airborne Warning and Control System data may be combined to develop a common operating picture and to control and coordinate all the systems sharing data. The range of complexity of requirements for data flow in such a mission underscores the significance of interoperability at every level. 2. Joint Chiefs of Staff. 1998. Department of Defense Dictionary of Military and Associated Terms, as amended through December 7, 1998, Joint Publication 1-02, Joint Chiefs of Staff, Washington, D.C.
OCR for page 66
--> Box 2.1 Interoperability Defined Operational Interoperability The ability of systems, units, or forces to provide services to and. accept services from other systems, units, or forces and to use the services so exchanged to enable them to operate effectively together. —Definition (1) in Joint Chiefs of Staff, Department of Defense Dictionary of Military and Associated Terms, as amended through December 7, 1998 (Joint Publication 1-02) and Chairman of the Joint Chiefs of Staff, Instruction 6212.01A: Compatibility, Interoperability, and Integration of Command, Control, Communications, Computers, and Intelligence Systems, June 1995. The ability of systems, units, or forces to provide services to or access services from other systems, units, or forces, and use the services to operate effectively together. —DOD Directive 5000.1, "Defense Acquisition," March 15, 1996. Technical Interoperability The condition achieved among communications-electronics systems or items of communications-electronics equipment when information or services can be exchanged directly and satisfactorily between them and/or their users The degree of interoperability should be defined when referring to specific cases. —Definition (2) in joint Chiefs of Staff, Department of Defense Dictionary of Military and Associated Terms, as amended through December 7, 1998 (Joint Publication 1-02). Interoperability is the ability of systems to provide dynamic interactive information and data exchange among C41 nodes for planning, coordination, integration, and execution of Theater Air Missile Defense operations. —Joint Theater Air Missile Defense Organization (JTAMDO). 1997. JTAMDO Master Plan. JTAMDO, joint Staff, Department of Defense, Washington, D.C., Chapter 7. One source of interoperability problems is incompatibilities in independently selected versions (e.g. software releases) of the same system. Thus, if one unit has standardized on version A of a given system and another on version B, capabilities supported by one system and not the other may well interfere with seamless interoperation between the two units. The committee observed several such situations in its visits to exer-
OCR for page 67
--> cises. Also, just as differences in modes of operation across the services can lead to non-interoperability, so can organizational differences within a service also lead to intra-service incompatibilities. One example that the committee heard about involved information security procedures and practices that were different in the U.S. Atlantic and U.S. Pacific commands, presenting difficulties for units that are reassigned from one theater to another. When thinking about C4I it is important to understand the distinction between joint systems and systems that are interoperable (Box 2.2). A system is designated as joint either to support an efficient buying decision for two or more services that will use it, or because the system will be subject to joint command. By contrast, to meet requirements for interoperability, services' systems must be able to share data in a timely, reliable manner that is operationally useful, and must operate across service or agency boundaries to support joint missions. Interoperability does not necessarily imply joint (multiple service) programs; interoperability can and must be achieved without jointness. Joint programs are but one of a number of management approaches for achieving interoperability of systems among the military services. Although many view interoperability as an issue arising in the context of two or more services (or nations), fielding a wide variety of mature systems built with little attention to supporting joint or coalition operations,3 in fact its sphere is broader. Indeed, during its site visits the committee heard several examples of C4I systems owned and operated by the same service that have difficulties in interoperating. For example, in one visit, the committee observed that with the Army Forward Area Air Defense Command, Control and Intelligence System and the Maneuver Control System there were difficulties in overlaying data from one system with data from the other. Finally, although it is a critical enabler for military operations, interoperability must be recognized as just one of several technical attributes of any system of systems. Indeed, other attributes will sometimes be in competition with interoperability and with each other; an appropriate balance must be sought. For example, there are trade-offs between security and interoperability. Interoperability can promote an attacker's access to diverse systems, thus facilitating the rapid spread of attacks. Also, ad hoc work-arounds to overcome a lack of inherent interoperability can 3. For example, in the Gulf War, C4I system incompatibilities made it impossible to electronically transmit the Air Tasking Order to Navy carriers, making delivery of paper copies necessary.
OCR for page 68
--> BOX 2.2 Interoperable Systems Are Not the Same as Joint Systems An airborne command and control system for air-to-air engagement could be designed as an Air Force system but its air picture would have to be displayable by Army air defense units and Navy ships. Likewise, the Navy might design a system for AEGIS air defense of the fleet, and the Army might design a surface air defense system. If an integrated air picture is to be shared by all three services, the data from each of the three service air defense command and control systems, which each provide an air picture based on data from the system's own sensors, must be exchangeable. Such service air defense command and control systems would be interoperable but not joint. The Army might design a surface-to-surface artillery command and control system. The Navy might design a ship-to-shore naval gunfire system. Because targets might be able to be attacked by either the Army or Navy weapons, it would be useful to be able to pass attack orders between the two systems—setting a requirement for interoperability but not jointness. As the Navy develops its Cooperative Engagement System to integrate both naval surface-to-air and surface-to-surface firepower, it would be useful to be able to share its target information with Army air defense and field artillery systems, and likewise share the Army system capabilities with the Navy system. If, however, it were ever desired to receive requests, determine targets, and automatically to fire on air and surface targets using either Army or Navy air defense or surface-to-surface firepower, it would make sense to develop a joint fire control system. Such a system would be considered joint because it would be employed by both services and would control the use of resources from both services. The U.S. Transportation Command could develop a command and control system to allocate air and sealift. The consumers of the command's transportation services may never need to use the system directly themselves, but would be interested in interoperability considerations such as the ease (form) of inputting lift requirements and of reading the output to determine what items need to be prepared for each lift asset. If this same system were to allow consumers to themselves conduct assessments of alternative deployments, it would then be considered a joint system because input form, run time, and output form might be of critical concern to consumers from all of the services. However, this does not mean that such a system would have to be developed and procured by a joint program office as opposed to that of a single service lead (with requirements input by the other services). With the advent of the Joint Force Air Component Commander, who integrates and can employ all air assets, the next version of software to
OCR for page 69
--> produce a joint air tasking order should probably be a joint development. This system should be used by both the Air Force and the Navy, should accommodate the uniqueness of each service, should decide or assist in the decision of the best assets to be employed (regardless of service), should integrate service assets (e.g., naval attack aircraft and Air Force tankers), and should provide a single, integrated order. This joint air tasking order development system could be used by both services to produce their air tasking orders when each is operating separately and could be used to produce a joint air tasking order when a Joint Force Air Component Commander has been established. introduce many hard-to-manage security problems. Another trade-off is the potential for interoperability problems posed by the introduction of new security features into part of a larger system of systems. Thus, in thinking about overall system functionality or performance, security requirements such as confidentiality, authentication, non-repudiation, integrity, and system availability must be considered together with interoperability. 2.1.2 Why Interoperability Is Important Why is interoperability, which is so difficult to achieve, so essential to implementing current doctrine as well as emerging concepts of operation? Experience in operations such as Desert Storm and Bosnia, as well as evidence from recent experiments and exercises, points to the dramatic improvements in operational effectiveness that are achievable using highly capable C4I systems. The leverage provided by a common operating picture and the rapid decision-making ability associated with it can dramatically change the pace, nature, and geographic range of engagement, providing major advantage to forces so enabled. Interoperability is a key to realizing these advantages. Interoperability is also an important factor in operational efficiency. Where interoperability is lacking, there is the likelihood that multiple systems are performing the same functions, or that information is being manually entered or processed multiple times. And lack of interoperability also means that personnel have to resort to work-arounds. Where interoperability is not in place, necessary transfer of information between systems may require speaking over a voice link or rekeying data from
OCR for page 70
--> printouts or handwritten notes, processes that are not only inefficient but error-prone as well. Military operations are typically joint, requiring that the C4I systems of multiple services work together effectively. Both the generally unpredictable nature of military contingencies and the wide range of non-traditional operations mean that forces and weapons are likely to be combined in novel, unanticipated ways to meet operational requirements and that their C4I systems may need to interoperate in ways not explicitly planned for in advance. Also, the new operational emphasis on rapid force projection, and the concept of early entry to halt an invasion, mean that there will likely be less time during a deployment to fix interoperability problems. Finally, the increasing size of the area over which combat operations take place—and thus the number of possible forces and weapons that must coordinate their attack—means that data is increasingly being exchanged between sensors, weapons, and systems that previously operated in a stand-alone manner. To meet such operational requirements, the different elements of the C4I system of systems will need to be more interoperable. Many important military missions require a high degree of interoperability to support cross-service collaboration. Some specific instances in the area of joint operations include the following: Close air support, which requires that Army ground troops be able to communicate their air support needs to Air Force ground attack airplanes in a timely and accurate fashion; Suppression of enemy air defenses, which in general requires the coordinated use of missiles and aircraft operated by multiple services; Theater missile defense, where, as noted above, data may be shared between weapons systems of different services or shared at the joint task force command and control systems level (or higher); Regional air defense, which requires the coordination of many air defense assets, from missile batteries and radar on the ground to airborne surveillance platforms and air defense fighters; and Deep-strike attacks and interdiction of enemy forces behind the front lines, which both require the coordinated use of airspace, strike aircraft, ground- and sea-based missiles, and long-range artillery. There is also ample evidence from experience that inadequate interoperability can cause major problems and significantly reduce military effectiveness. A recent report by the Secretary of Defense noted that ''from Grenada in 1983 to Operation Desert Storm in 1991, joint operations have been hindered by the inability of forces to share critical information at the
OCR for page 71
--> rate and at the locations demanded by modern warfare."4 Recent examples include the following:5 During Operation Urgent Fury, the invasion of Grenada, the Marines and the Army Rangers could communicate only through offshore relay stations, because their use of radio frequencies was uncoordinated. As a result, the Marines did not know in one instance that the Army Rangers were "pinned down without adequate armor."6 During the Joint Warrior Interoperability Demonstration in 1996, problems associated with network configuration did not support "timely interoperability" with coalition forces. According to the Joint Warrior Interoperability Demonstration report, limitations of the multilevel security systems, which were intended to allow information to be delivered to coalition forces, required manual intervention even for use of simple applications such as e-mail. This need for manual intervention "made it extremely difficult to conduct U.S./coalition collaborative planning since information . . . was never fully synchronized for both U.S. and Allied planning requirements."7 According to the General Accounting Office, 43 "significant interoperability problems" associated with 15 C4I systems and weapons, such as the AEGIS and Patriot systems, were identified by the Joint Interoperability Test Command during four joint exercises held in 1996 and 1997. These interoperability problems, most of which "were caused by 4. William S. Cohen. 1998. Secretary of Defense Report to Congress: Actions to Accelerate the Movement to the New Workforce Vision, Department of Defense, Washington, D.C. This report also tasked a study to develop an improved, cross-service process for developing joint capabilities. 5. The Joint Interoperability Test Center of the Defense Information Systems Agency is responsible for testing and evaluating C4I acquisitions and systems, as well as identifying and solving C4I interoperability problems. As part of its work, it compiles the quarterly compilation of lessons learned, which addresses "C4I interoperability problems/issues related to Joint/Combined C4I and integration of information systems within the Defense Information Infrastructure." For additional information, see the Joint Interoperability Test Center home page at <http://www.jitc.fhu.disa.mil>. 6. Col. Stephen E. Anno and Lt. Col. William E. Einsphar (no date). Command and Control and Communications Lessons Learned: Iranian Rescue, Falklands Conflict, Grenada Invasion, Libya Raid, Air War College Research Report No. AU-AWC-88-043, Air University, United States Air Force, Maxwell Air Force Base. Information can be obtained through the Joint Electronic Library at <http://www.dtic.mil/doctrine/jel/research_pubs.htm>. 7. Defense Information Systems Agency (DISA). 1996. Joint Warrior Interoperability Demonstration 1996 Report, Defense Information Systems Agency C4I Modeling, Simulation and Assessment Division, DISA, Arlington, Va.
OCR for page 72
--> system-specific software problems," could potentially "result in the loss of life, equipment, or supplies."8 In short, interoperability is essential to operability—that is, forces cannot operate effectively without a high degree of interoperability among their systems. Unfortunately, interoperability is often treated as a potentially desirable but nonessential, element of C4I programs, and a sufficient degree of interoperability, especially inter-service, is not currently seen by managers as a pass-fail criterion for their programs. Consequently, interoperability requirements tend to be one of the first things sacrificed when budgets force program cost reductions. That said, universal interoperability is neither achievable nor necessary. Not every C4I system on the battlefield needs to interoperate with every other one. Nor is universal interoperability—which might be thought of as allowing all information in all systems to be seamlessly exchanged and interpreted—technically feasible, given the rate of change in both technologies and missions. The importance of achieving interoperability, determination of what and how much is sufficient, and decision making about allocation of resources to achieve interoperability can be addressed only in an operational context. 2.1.3 Dimensions of Technical Interoperability On a digital battlefield, sensors generate bits, communications channels transmit bits, computers process bits, commanders act on information represented as bits, and weapons are directed by messages composed of bits. These bits are the underlying electronic representation of data and information, and to be used they must be interpretable according to some agreed-upon definitions. For two C4I systems to effectively interoperate, they must be able not only to exchange relevant bitstreams but also to interpret the bits they exchange according to consistent definitions—merely providing information in digital form does not necessarily mean that it can be readily shared between C4I systems. Interoperability also requires that systems are interoperable at the data level—that the format and semantics of the data are also coordinated so as to permit interoperation. One significant instance where this requirement arises is in the exchange of geographical coordinates. To launch 8. General Accounting Office. 1998. Joint Military Operations: Weakness in DOD's Process for Certifying C41 Systems' Interoperability, GAO/NSIAD-98-73, General Accounting Office, Washington, D.C.
OCR for page 73
--> a missile against a target, it is necessary to know the location of the missile launcher as well as that of the target. The specification of a location implies the existence of a common coordinate system (and hence a model of Earth) within which both target and launcher locations can be specified. Obvious difficulties can arise if the locations of the target and launcher are specified with respect to different Earth models. If the sensor and launcher are not using the same Earth model, a transformation of the sensor-reported location of the target into the launcher's coordinate system will be necessary. Since it has only been relatively recently that the idea of using non-co-located sensors for fire control has become practical, the implicit assumption of identical Earth models for target and launcher may well not be a valid one. Section 2.3.4 discusses some approaches to the data interoperability challenges. Thus technical interoperability places detailed demands at multiple levels, which range from physical interconnection to correct interpretation by applications of data that is provided by other applications. 2.2 Why Achieving Interoperability Is Difficult 2.2.1 Challenges Common to All Large Enterprises Experience in the private sector suggests that the following factors (among others) often operate to inhibit or slow achievement of desired system interoperability. Tension Between Immediate and Future Needs Operational units (in the DOD context, the CINCs as the warfighting authorities) in an organization often have a perspective very different from that of the planning units (in the DOD context, e.g., the Office of the Secretary of Defense, Joint Chiefs of Staff, and the service chiefs as the policymakers, allocators of resources, and providers). Operational units are concerned with the capabilities of today's systems in the short term, whereas planning units are concerned with the capabilities of tomorrow's systems, over the longer term. For the planner, interoperability is a capability that must be designed into a system. For the operator, interoperability is often achieved by working around problems, e.g., deciding what parts of a system to use or not use, creating patches, and modifying policy or doctrine associated with its use. For the planner, changes in system capability (i.e., changes in feature and function) are important. To the operator, changes in operating
OCR for page 74
--> capability (perhaps enabled by changes in deployed system capability) have greater significance. For the planner, operational doctrine and tactics are driven by what can be imagined when the force is fully equipped and the new technology or system is deployed. For the operator, they are driven by deployment (perhaps partial) of a system and the resulting capabilities of the unit. Large organizations recognize that operational considerations (e.g., training, doctrine) must be an integral part of system acquisition. But maintaining such a focus is difficult when operators believe (with some justification) that planners are not rapidly responsive to their immediate needs, and the planners believe (with some justification) that an overemphasis on immediate needs will not enable operating units to fully realize the benefits of new capabilities. Tension Between Local and Global Needs Optimizing overall system performance requires a full understanding of the trade-offs entailed by different choices. However, individual units within an organization, especially those that seldom interact with other units, are strongly motivated to solve their own pressing problems, even if doing so makes it harder for them to interact with other units. In addition, the fact that many acquisition programs have very long time lines increases the pressure to deploy independently developed solutions. The most likely result of such independent development is a patchwork of systems that are even less interoperable.9 Inability to Anticipate All Relevant Scenarios for Use Many of the most common applications of information technology today were unanticipated when the technology was initially deployed. For example, when the ARPANET (the forerunner of the Internet) was first deployed, e-mail was considered a secondary application, whereas email is today one of the most often used Internet applications. In general, it is difficult to anticipate in detail how information systems will be used—a difficulty that is multiplied in an uncertain environment. For example, a 9. This phenomenon was seen in commercial industry 20 to 30 years ago. Early application of computing technology that automated the functions of individual business units took place in parallel without attention to enterprise-wide concerns, compounding later interoperability problems. Later developments, such as a shift in technology and approach from reliance on departmental minicomputers to use of client-server configurations, helped resolve these problems.
OCR for page 119
--> tion thread of the common operational picture (COP) is the data elements in the "track file"; this would be an appropriate first thread on which to focus attention. COP programs have been conceptualized to provide capabilities at several levels. For example, within the Global Command and Control System (GCCS), the COP provides a common operating picture at the headquarters level. Other examples of operational capabilities on which to focus include the common tactical picture (CTP) and the SIAP—both capabilities critical to achieving effective joint operations and status reporting up the chain of command. It is understood that the lead for developing C4I architectures is a shared responsibility of the Directorate for C4I Systems of the Joint Staff (operational architecture) and Assistant Secretary of Defense for C3I (systems and technical architectures), with support coming from other DOD elements depending on which mission slice is selected (e.g., from the Joint Theater Air Missile Defense Organization if theater missile defense were chosen as the mission slice). Given the urgent need to develop an operational and system architecture to guide ongoing development, the committee recommends that the Directorate for C4 Systems of the Joint Staff and the Assistant Secretary of Defense for C3I select an appropriate mission slice and initiate an activity to develop operational and systems architectures as a mechanism for identifying and prioritizing interoperability needs and problems—both today and prospectively. Again, the consideration of available foundational work is important and suggests that a candidate would be a collaborative Joint Theater Air Missile Defense Organization/Ballistic Missile Defense Organization effort on the theater missile defense mission—an activity that would yield specific results for a crucial joint mission and also serve as a pilot of the "mission slice" approach.31 Also, the committee believes that it would be useful to draw on service efforts to establish architectures for guidance in selecting mission slices and management approaches. Note that it is not the intent of this recommendation to suggest that DOD should concentrate only on limited domains. The focused activities recommended here are intended to complement the standards and common infrastructure elements that provide a necessary foundation for mission-specific capabilities.32 31. Another candidate mission slice is joint strike—the use of air, sea-based, and land forces to conduct air and artillery strikes behind enemy lines. Execution of this inherently joint mission depends on a demanding set of joint tasks such as dynamic target tasking and managing airspace use (deconfliction). 32. There are also ongoing efforts by the Air Force Science Advisory Board to explore other broader approaches (in addition to JTA and common infrastructure) that complement the mission slice approach.
OCR for page 120
--> Recommendation I-2: The Secretary of Defense should establish a joint C4I integration and interoperability activity to address integration and interoperability throughout the entire life cycle of C4I systems. The committee believes that an appropriate augmentation of current DOD activities for promoting and facilitating C4I interoperability should focus on three areas: more cross-service testing that starts early in the development process, an increased emphasis on end-to-end field testing, and greater end-to-end interoperability support in operational contexts. Cross-service testing starting early in the development process . In particular, the testing component of current interoperability efforts is technically oriented and directed primarily at system-to-system testing when the development effort nears completion. Testing in general is oriented toward standards compliance or system acceptance rather than mission performance. The committee believes that to the extent possible, interoperability should be analyzed, assessed, and driven "top-down" by considerations of operational significance as well as facilitated "bottom-up" by the C4I technical community. Focusing on systems within a mission slice, such testing would augment current efforts by testing at application and data layers much earlier in the development process than current practice, perhaps even against paper requirements. Early attention to system-to-system testing for interoperability would make it easier to synchronize the objectives and time lines of different programs for C4I systems that must interoperate, reduce the effort needed to achieve interoperability, and decrease the time line required for addressing interoperability problems in the field by providing ''preventive medicine." In addition, it would avoid the cost and complexity entailed when problems are fixed late in the development process. Note that a cross-service development activity is consistent with the desire articulated by the Secretary of Defense in response to Section 912(c) of the Defense Authorization Act for FY 1998. Specifically, the Secretary of Defense expressed interest in ways to establish a joint command, control, and communication integrated system development process that focuses on developing a joint architecture to guide design and achieve integrated systems development.33 Ongoing interoperability assurance in operational contexts. Notwithstanding "best efforts" to address interoperability problems before systems are fielded, unanticipated interoperability problems invariably arise as C4I systems are composed and configured in untested combinations in 33. See William S. Cohen. 1998. Secretary of Defense Report to Congress: Actions to Accelerate the Movement to the New Workforce Vision, Department of Defense, Washington, D.C.
OCR for page 121
--> the field to support particular operational needs. Such problems are increasingly complex, demanding technical sophistication to address "higher-level" issues such as data interoperability. DOD does undertake some activities that address end-to-end C4I interoperability, but the committee is unaware of a process or mechanism in the DOD that systematically addresses C4I interoperability on an end-to-end basis, in a real-world operational setting, in a manner that provides assurance for commanders who will need to support critical operational jobs. Interoperability support for deployed forces. Deployable operational support for interoperability would help joint task force commanders to address and respond to interoperability problems and issues as they inevitably arise in the field. Deployed in much the same way that the Joint Communications Support Element deploys, "field interoperability support teams" would deploy as an initial cadre with a joint task force first to guide the interconnection of C4I systems in-theater and then to provide sustaining support as required, focusing on integrating and ensuring the interoperability all CINC/service-provided C4I systems (specifically including decision-making/decision-executing information systems as well as communications systems). Field integration/interoperability support teams would involve designated sets of broadly skilled information systems and networking personnel and tools to support their work. Using specialists who are intimately familiar with C4I systems being deployed would increase the likelihood that interoperability problems could be resolved under the extreme time pressures that characterize many operational deployments. Because they would be intimately familiar with the design and development foundations of fielded C4I systems, field integration support teams would have an important advantage over today's deployed "signal" units with respect to certain classes of problems. In addition, they would have the technical background to be able to speak knowledgeably to system suppliers and vendors to obtain high levels of technical support to fix interoperability problems in the field (e.g., by obtaining software patches).34 The committee also notes that force interoperability would be more easily achieved, and the burden of field integration reduced, if planning for contingencies were less ad hoc. Deliberate operational planning— 34. Currently, commanders may find it impossible to solve significant interoperability problems between C4I systems rapidly enough to be useful in a contingency. They thus must resort to suboptimal work-arounds employing whatever communications links can be established. With appropriate significant technical support, more problems could be solved rapidly enough to be relevant to an operational deployment.
OCR for page 122
--> perhaps in conjunction with predesignation of joint task force commanders—by the force provider would permit much better advance knowledge of which forces would be called upon to interact in a given contingency. With such knowledge, the force provider would be in a better position to focus testing, training, and the like, so as to maximize the interoperability of forces that would be called upon to carry out a particular deployment. Development, field testing, and operational support draw on the same knowledge and experience base and are inherently synergistic—testing builds expertise that is valuable for field support, and field activities improve future design, development, and test efforts. Also, as an organization that includes both developers and testers, and that has direct contact with end users in the field, a joint C4I integration and interoperability activity would provide a collaborative environment that would foster less adversarial relationships more akin to those increasingly evident in the commercial sector (see section 2.4 and Box 2.8). To build and sustain the expertise that field integration/interoperability teams need in order to be able to address interoperability problems "on the fly," the joint C4I integration and interoperability activity would have a peacetime role that includes: Interaction with users. The joint C4I integration and interoperability activity would interact with users in the conduct of acceptance tests as well as the subsequent readiness tests that are used by forces in deciding whether to field an accepted system. During its site visits, the committee observed several instances of such collaboration. 35 Conducting cross-service/agency interoperability tests. This work would include identifying and synchronizing test opportunities as programs progress through their individual development cycles (within the spiral model framework). Participation in joint and service-sponsored tests and exercises. Education and training of personnel on interoperability issues. For example, the joint C4I integration and interoperability activity would train field operational personnel to prevent the decreased interoperability that can result from applying ad hoc solutions to field problems. 35. In its site visits, the committee observed a close interaction between users and developers at the Force XXI Advanced Warfighting Experiments in Fort Hood. It also observed the USAF 605th Test Squadron, which is responsible both for acceptance tests that are part of the acquisition cycle (i.e., tests that the new components satisfy a contractual requirement) and readiness tests that are part of a force's decision to deploy an accepted C4I system (i.e., tests that the force knows how to combine the new C4I component with existing components and how to apply them). Both of these examples illustrate the right synergy between developers and users.
OCR for page 123
--> C4I configuration and version management. The joint C4I integration and interoperability activity would develop rules and guidelines to identify configurations of C4I systems—including software and hardware versions—that are known to interoperate with others and provide codified guidance to operational commanders as to what units and C4I systems would interoperate in a deployment. Development of fixes and work-arounds to resolve interoperability problems. Dealing with interoperability topics at the "higher level" demands being conversant with variations among successive software and hardware releases associated with a particular product line or functionality. This knowledge would also be transferred to operational commands in the form of advice as to what units and systems could and could not be made to interoperate in a deployment. Doing the work described above would keep personnel familiar with the "building blocks" that could be delivered to the field and from which an end-to-end joint capability would be configured. During exercises and operational deployments, the joint C4I integration and interoperability activity would offer advice to commanders in planning deployments and provide field support to fix interoperability problems. The technical expertise regarding C4I systems, together with the operational perspective gained from its involvement with joint exercises and deployments, makes the joint C4I integration and interoperability activity a powerful mechanism for improving the coupling between the development community and the community of users. Where Should the Joint C4I Integration and Interoperability Activity Be Established? The committee believes that specifying function is more important than specifying organization. Nonetheless, it notes that several organizations—both existing and proposed—have missions that overlap with the proposed joint C4I integration and interoperability activity: The Joint Interoperability Test Center in Fort Huachuca, Arizona, plays an important role in technical interoperability testing. Also, while the Joint Interoperability Test Center does not have a formal role for testing interoperability across systems from different services at a functional or operational level (nor does any other DOD agency or organization), its personnel in fact do provide a measure of operational support to exercises. In fact, briefings from the Joint Interoperability Test Center suggested to the committee that this organization is placing increasing emphasis on field support.
OCR for page 124
--> Cross-service development activities are undertaken by the major service C4I developers (the Air Force Electronic Systems Command, the Army Communications and Electronics Command, and the Navy Space and Naval Warfare Systems Command), the associated program executive officers and program managers, the Defense Information Systems Agency, and end users. Existing and emerging service developer capabilities include the Electronic Systems Command's Command and Control Unified Battlespace Environment, the Communication and Electronics Command's Digital Integration Laboratory, and the Space and Naval Warfare Systems Command's Integration Laboratory and Advanced Concepts site, as well as other efforts to establish a joint developer's test bed. Including service developers in an activity that provides field support would add a measure of detailed expertise that is often needed to resolve interoperability problems in the field. The proposed interconnection of service/agency development facilities resembles the concept of the battle laboratory "federation" associated with the recently formed Joint Battle Center but is intended to emphasize developmental phase, working level, technically based testing prior to and after formal evaluations. The Under Secretary of Defense for Acquisition and Technology and the Assistant Secretary of Defense for C3I were tasked by the Secretary of Defense to examine ways to achieve objectives that are, in part, similar to the proposed joint C4I integration and interoperability activity.36 The tasking specifically requested submission of an implementation plan to streamline the acquisition organizations, work force, and infrastructure. Despite the general focus on streamlining and infrastructure redirection, the section of the Secretary's report devoted to the restructuring of research, development, testing, and evaluation identified C4I shortfalls vis-à-vis the conduct of joint operations and directed that a study group be formed to address responsive improvements.37 36. This tasking derived from an April 1, 1998, Secretary of Defense response to congressional direction in Section 912 (c) of the national Defense Authorization Act for Fiscal Year 1998. 37. See William S. Cohen. 1998. Secretary of Defense Report to Congress: Actions to Accelerate the Movement to the New Workforce Vision, Department of Defense, Washington, D.C. Quoting from the Secretary's report: "From Grenada in 1983 to Operation Desert Storm in 1991, joint operations have been hindered by the inability of forces to share critical information at the rate and at the locations demanded by modern warfare. To attack this problem, I will direct the Under Secretary of Defense (Acquisition & Technology) and the Assistant Secretary of Defense (Command, Control, Communications, and Intelligence) to create a study group that will examine ways to establish a joint command, control and communication integrated system development process that focuses on developing a joint architecture to guide design and achieve integrated systems development."
OCR for page 125
--> A study group composed of the commanders of the three primary service C4I acquisition commands (the Air Force Electronic Systems Command, the Army Communications and Electronics Command, and the Navy Space and Naval Warfare Systems Command) was established and, under the guidance of the Under Secretary of Defense for Acquisition and Technology and the Assistant Secretary of Defense for C3I, has evolved a concept for improving C4I integration and interoperability. As of this writing, the fundamental concept involves both (1) working across the acquisition/development commands and related organizations to ensure that systems are "built and tested joint" and (2) establishing tri-service acquisition/development command activities to respond to the needs and problems of the CINCs. An acquisition/development command management forum, the Joint C2 Integration and Interoperability Group, which reports to the Assistant Secretary of Defense for C3I and has mechanisms in place to incorporate the perspectives of other stakeholders, has been established. The committee understands that a study report and implementation plan have been submitted to the Undersecretary of Defense for Acquisition and Technology. Although the specifics are still evolving, the committee applauds this initiative and views it as potentially addressing the intent of the cross-service development component of the committee's recommendation. As of this writing it is less clear if that would satisfy the on-call, high-level field support component also included in the committee's recommendation. Recommendation I-3: The Secretary of Defense, the Assistant Secretary of Defense for C3I, and the Chairman of the Joint Chiefs of Staff should establish processes to assess C4I interoperability on a regular basis. Interoperability is typically assessed by DOD through non-comprehensive perspectives that are focused, for example, on standards, COE compliance, data models, or certification criteria and how individual systems match up to such criteria or standards. Although a definitive, rigorous analytical approach at a detailed level could be sought, what is key is an approach that provides an overview for management attention at upper levels of both the user (e.g., Joint Chiefs of Staff and the CINCs) and the developer (e.g., the Assistant Secretary of Defense for C3I and the services) communities. In this approach, the interoperability management challenge becomes one of addressing the state of interoperability throughout the enterprise, rather than attempting to strictly measure every variable in detail in each possible scenario.
OCR for page 126
--> Recommendation I-3.1: The Assistant Secretary of Defense for C3I and the Joint Chiefs of Staff should develop a set of "interoperability scorecards" as a basis for management, covering the spectrum from compliance with standards to successful end-to-end mission support. A scorecard approach, which would be useful in assessing the status of cross-service C4I interoperability, is recommended. This approach would support problem prioritization, diagnosis, and correction, as well as operationally based assessment of the state of C4I interoperability for the use of system managers (e.g., the Office of the Assistant Secretary of Defense for C3I and the Military Communications and Electronics Board) and operational users (e.g., CINCs or joint task force commanders). The scorecard approach cannot provide sophistication and quantitative theoretically grounded measures. Rather, the fundamental motivator is to move to a point that interoperability is analyzed, assessed, and driven top-down by considerations of operational significance. The approach uses three scorecards—technical, systems, and operational—corresponding to the elements of the architectural triad. The technical compliance scorecard would be used to assess a system's implementation from a technical interoperability perspective. It would take the form of a system profile or list for scoring each system implementation with respect to compliance or non-compliance with relevant standards and guidance. The systems interoperability scorecard would measure system to-system interoperability and would take the form of a matrix displaying the ability of all pairs of systems to interact with each other. The operational interoperability scorecard would be used to assess the ability of a set of systems to satisfy specific node-to-node information flow requirements as well as the collective set of information flows needed to satisfy a defined mission or mission slice. Assessment requires that responsibility is assigned for (a) the development and definition of criteria, (b) actual conduct of the assessment, as well as (c) responsibility for ensuring that the results of the assessments translate into actions to remedy issues uncovered in the assessment. Responsibility should be assigned as follows: Development and definition of criteria. For assessment of technical and systems interoperability the committee believes that the Assistant Secretary of Defense for C3I should have the lead in development of criteria, and definition of operational interoperability criteria should be a joint responsibility of the Joint Chiefs of Staff and the combat commands. Conduct of interoperability assessments. Given the Defense Information Systems Agency's Joint Interoperability Test Center's role in testing compliance with the Joint Technical Architecture, it is appropriate
OCR for page 127
--> that these organizations conduct the technical interoperability assessment. System developers and the organization proposed in Recommendation I-2 above are the logical responsible organizations to assess system interoperability. The operational interoperability assessments should be conducted by an appropriate organization as tasked by the Joint Chiefs of Staff (e.g., the Joint Theater Air Missile Defense Organization for theater missile defense). The responsible organizations should ensure that users play a key role in making such assessments. Without a process for continual assessment for interoperability, the user will have little sense for what interoperability problems need fixing and what their impact might be. Accountability for the results of the assessments. Accountability and responsibility for remedying shortcomings uncovered should lie with the Assistant Secretary of Defense for C3I in the case of the technical and system assessments and with the Joint Chiefs of Staff and the operational commands in the case of operational interoperability assessments. Recommendation I-3.2: The Chairman of the Joint Chiefs of Staff should establish a process to incorporate C4I interoperability into readiness reporting. Achieving and maintaining an adequate level of interoperability pose significant challenges. Indeed, given the large number of C4I systems that are increasingly expected to interoperate and given the increasing rate at which new hardware and software versions are being fielded, especially as the spiral development model is adopted, the state of interoperability in fielded systems requires ongoing attention. To help in assessing progress toward meeting these challenges, C4I interoperability should be built into readiness reporting. It must, however, be done in a way that recognizes the characteristics of current combat readiness reporting, which emanates from the combat unit (i.e., a battalion, squadron, or ship) and reports on the status of things controlled directly by the unit or supported directly by its parent command (e.g., training, manning, availability of spare parts, in-commission rates for combat equipment). The level at which C4I interoperability readiness can be measured and reported differs from the level of the factors included in current combat readiness reporting. Individual combat units are not necessarily in a position to ascertain the status of C4I systems external to their own units—the key issue in determining the ability to conduct joint combat operations. It is at echelons of command above combat units, particularly those with a joint perspective, where there is today no formal combat readiness reporting system, that the readiness of C4I systems can best be assessed.
OCR for page 128
--> Also, C4I is a more indirect contributor to combat power than factors that can be directly tied to a particular units' combat readiness. The system that the Joint Chiefs of Staff develops must focus on assessing the readiness of forces to conduct end-to-end missions. The readiness reporting must be based on a realistic set of scenarios for how units are to be employed. It may be appropriate to focus assessment efforts in the same mission slices as those in which the activities proposed in Recommendation I-1 are conducted. The joint force provider, the U.S. Atlantic Command, is in a unique position to provide cross-service visibility of the contribution of interoperability factors to readiness. Its ability to do so would be enhanced if it were to preplan which forces would be expected to be deployed in a given contingency, an approach that would also enable better assessment of interoperability as an element of readiness for that contingency. Recommendation I-4: The services and agencies should designate an activity within the program offices for C4I systems (and weapons systems with embedded C4I) to be explicitly responsible for resolution of architectural and system-level issues that determine interoperability. The committee believes that management attention to the interoperability of C4I systems is today often not an assured process. That is, while today's acquisition system does acknowledge the importance of C4I interoperability in its various directives, in actual practice the management attention afforded to C4I interoperability depends strongly on the temperament and inclinations of the individual program manager. Program managers who "buy into" the vision of interoperability pay a great deal of attention to that subject, while those who do not pay far less attention to it. The focus of this recommendation is not the development of additional acquisition policy but rather the filling of a gap in implementation and practice in program management. The establishment of an "interoperability cell" or equivalent in C4I program offices would provide a central point of focus for interoperability issues. The fundamental principle of this activity is that for each C4I program there must be an activity charged with looking outward, cross-service, at interoperability issues. This cell would be responsible for revising or modifying architecture as needed to accommodate changes in doctrine, tactics, techniques, procedures, and equipment; engaging the stakeholders in a particular C4I system in the problem of defining and achieving interoperability for that system; and negotiating interoperability issues with those responsible for development/upgrade of "neighboring" systems. In its efforts, an interoperability cell could be expected to take a pragmatic approach that narrows the scope of the systems that must be
OCR for page 129
--> considered by the architectures (though not necessarily to those that are immediately adjacent to any given program), and limit the scope of the interoperability effort to particular configurations of components. In other words, interoperability cannot be realistically expected across an unlimited number of releases or versions. Such "bottom-up" negotiation of interoperability issues is intended to complement "top-down" architectural and common infrastructure efforts. The cell would also be responsible for elements that constitute an investment in future interoperability, such as metadata and appropriate interfaces. The appropriate placement for an interoperability activity can vary. For a large program, placement within the program manager's office may be advantageous. In other cases, placement within a program executive office or service acquisition command may make sense—both for reasons of efficiency and to ensure that the "cell" has a sufficiently broad perspective. Somewhat similar functions have been performed by service elements such as the Air Force Electronic Systems Command, the Navy Space and Naval Warfare Systems Command, and the Army Communications and Electronics Command. However, there is no clear analogy to these organizations for joint systems.
Representative terms from entire chapter: