Realizing the Potential of C4I Fundamental Challenges (1999) / Chapter Skim
Currently Skimming:
2 Interoperability
2 Interoperability
Pages 64-129
The Chapter Skim interface presents what we've algorithmically identified as the most significant single chunk of text within every page in the chapter.
Select key terms on the right to highlight them within pages of the chapter.
From page 64... ...
1996. Joint Vision 2010, Joint Chiefs of Staff, Washington, D.C.
|
From page 65... ...
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.
|
From page 66... ...
66 REALIZING THE POTENTIAL OF C4I: FUNDAMENTAL CHALLENGES One source of interoperability problems is incompatibilities in independently selected versions (e.g., software releases) of the same system.
|
From page 67... ...
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.
|
From page 69... ...
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.
|
From page 70... ...
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)
|
From page 71... ...
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 |
From page 72... ...
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.
|
From page 73... ...
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 policy makers, allocators of resources, and providers)
|
From page 74... ...
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.
|
From page 75... ...
Furthermore, they often represent significant investment, so that replacing them with new, more interoperable systems is not a nearterm option. Managing in the Face of Rapid Technological Change Because the underlying information technologies will certainly improve significantly over the lifetime of a system's development and deployment, it is desirable to plan for the incorporation of these improvements during the later phases of system deployment.
|
From page 76... ...
On the other hand, the very latest technologies are not always the best choice; to maximize the likelihood of maintaining interoperability, it is prudent to select relatively stable technologies that are achieving widespread adoption and are likely to enjoy longer-term support. · Backward compatibility.
|
From page 77... ...
In addition, policy or doctrine must deal with the need for units equipped with new generations of technology to interact with others not comparably equipped (the issue of how to address this question in military doctrine is addressed in Chapter 4~. Proprietary Technologies Use of off-the-shelf products and subsystems built to commercial standards can reduce costs and development time and can make interoperability easier to achieve.
|
From page 79... ...
Thus, the time lines for developing these components must be synchronized if interoperability is to be effected in a timely manner. Such synchronization refers not only to product delivery at the proper times, but also to matters such as timely decision making and testing within each program so that decisions are made that facilitate interoperability and problems uncovered soon enough to not cause additional difficulties later.
|
From page 80... ...
Despite the best intentions and early planning of C4I system designers, there are likely to be many cases where user needs surpass those envisioned by the authors of the original requirements. In all of these cases there is a need for architectural efforts across systems aimed at accommodating future unanticipated interoperability requirements.
|
From page 82... ...
Flexibility to Accommodate Variations in Command Structures Command relationships determine the overall nature of information flows, and joint task force and theater commanders have the discretion, and the responsibility, to determine these command relationships as they think best. Commanders who choose unconventional command relationships may well require C4I linkages that have not been attempted before.
|
From page 83... ...
iiAs discussed in section 2.2.1, backward compatibility is supported in the commercial sector for only a limited number of generations. Such practices are reasonable in the commercial world given the rate at which users are upgrading hardware.
|
From page 84... ...
Program managers are generally held accountable for the performance, cost, and schedule of their piece of a system, not for the performance of the whole system of systems. 2.3 TECHNICAL APPROACHES TO INTEROPERABILITY As noted above, all large organizations have trouble achieving interoperability.
|
From page 85... ...
that exchange information only with great difficulty. Because reengineering requires an understanding of information flows that cut across old organizational boundaries, it lays the intellectual groundwork for an architecture that will support those flows.
|
From page 86... ...
· Reducing the number of interaction points between systems. Reducing the complexity of intersystem dependencies facilitates more rapid reconfiguration of systems to meet operational requirements.
|
From page 87... ...
2.3.3 Standards A key element of architecture is the establishment of technical standards. Such standards define common elements, such as user interfaces, i5Adapted from Computer Science and Telecommunications Board, National Research Council.
|
From page 88... ...
Technical standards offer a number of advantages for a system architect: · They make it easier to exploit changing technologies (Box 2.5~. For example, standardized interfaces facilitate interoperability because a component that conforms to a given standard can "plug" into a standard interface without concern for how the component on the other side of the interface works internally.
|
From page 89... ...
INTER OPERABILITY 89 component designer. The important thing is the operational scenarios that a system is expected to support.
|
From page 90... ...
DOD, despite its size, is a small force in the overall marketplace, which suggests that if DOD attempts to create its own standards, the standards will not be viable in the long run except where they are relevant only to military applications and do not have to compete with analogous standards in the commercial sector. DOD is more likely to be successful if it exploits well-articulated and tested commercial standards wherever possible in C4I systems.
|
From page 91... ...
· Extensible data model. Another approach to achieving data interoperability uses an extensible data model and standardized interface.
|
From page 92... ...
Legacy systems, which have been built around frequently unique data definitions, pose a major challenge to interoperability. Industry has developed a number of approaches by which systems not designed up-front for interoperability can interoperate to exchange information: · The data "bus" approach.
|
From page 93... ...
Examples that come readily to mind include DOD's effort to establish ADA as the universal programming language (Box 2.6~. The lesson to be learned is that in the hope of achieving a grand and universal solution, it is easy to grossly underestimate the complexity associated with a project of such large scale, the difficulty of managing it, and the level of talent required at all levels to achieve success.
|
From page 95... ...
Then a substantial burden for interoperability, as well as continued development of the components, is passed to the commercial sector. Strategies for using COTS are discussed in section 4.3.3.
|
From page 96... ...
Testing is critical to achieving interoperability and has an especially large payoff if conducted concurrently with development. Many interoperability problems are subtle, manifesting themselves only in certain sets of circumstances, and so are hard to uncover, and they demand a great deal of empirical work and testing to resolve.
|
From page 97... ...
It is typically performed in a laboratory, where two or more systems can be interconnected. Involving multiple systems and suppliers, it is usually more complex and expensive than conformance testing.
|
From page 98... ...
interoperability. · Field testings assesses the extent to which a system satisfies users' operational needs in a "real-world" setting, which differs from the controlled environment of developmental and preproduction testing: system configurations in the field (e.g., software releases, intermediate communications, etc.)
|
From page 99... ...
Field testing involves functional testing and followon testing: Functional testing, the initial test in the field, cannot occur until people in the field have been trained in both the system and the business processes that the system will support. Functional testing involves configuring systems to meet the unique demands of particular customers, integrating products with the embedded base of systems (including earlier generations of the same product)
|
From page 100... ...
Responsibility for Interoperability is distributed across DOD, and each of the major players has at least one entity charged with responsibility for Interoperability issues. For example, the Defense Information Systems Agency has the Joint Interoperability Test Command, the U.S.
|
From page 101... ...
The Toint Operational Architecture is intended to identify mission objectives, information exchange requirements, and logical connectivities among and within command and control units or organizations. The Toint System
|
From page 102... ...
As far as the committee has been able to determine, the Joint Operational Architecture was originally intended to be a construct covering all military operations. For example, the 1998 Annual Report of the Secretary of Defense states that "the DOD is developing an agency-wide Joint Operational Architecture that describes the tasks and activities, operational elements, and information flows required to accomplish or support the missions of the DOD."20 The Information Superiority Campaign Plan of the Joint Chiefs of Staff calls for "the development of a high-level, C4 Joint Operational Architecture that integrates the joint warfare functions, from national level through operational level, into implementations of the JV2010 [Joint Vision 2010]
|
From page 103... ...
Used in combination, these would define interoperability requirements to support operational mission information flows. For example, the Operational Architecture and Systems Architecture for a particular operational activity would define which service-developed systems would have to exchange what information over what media in what format.
|
From page 104... ...
The ultimate intent of the initiative is to bring all these data models together into one DOD-wide standard. One tangible result of this initiative is the DOD Command and Control Core Data model, which is now contained in the Defense Data Dictionary System managed by the Defense Information Systems Agency.
|
From page 105... ...
Although some qualitative assessments of the status of a unit's C4I systems, including interoperability, may enter into readiness assessments using today's process, the increasing importance of and reliance on C4I support of military operations suggest that the status and health of C4Ialong with interoperability and other key aspects be introduced as a more explicit and objective (rather than implied and subjective) factor.
|
From page 106... ...
2.6.2 A Systems Interoperability Scorecard The systems view of an architecture focuses on the information and communications systems that are brought to bear to support the information flows required to accomplish operational missions and attempts to measure the degree to which the various system pairs can effectively interoperate in context to meet these information flow requirements. These information flow requirements indicate the content and nature of the information and services needed, their directional flow, and the constraints and demands imposed by the operational environment.
|
From page 107... ...
2.6.3 An Operational (Mission-Enabling) Interoperability Scorecard The operational view of an architecture addresses particular mission or operational slices, such as targeting, close air support, force sustainment, or the like, of a broader operational setting.
|
From page 108... ...
A scorecard used to assess interoperability from an operational architecture perspective would focus on the ability to satisfy specific node-tonode information flow requirements (see Figure 2.3) and the collective set of flows needed to satisfy a defined mission or mission slice.
|
From page 109... ...
Parts of DOD are well aware of a defense-wide problem in exploiting rapidly changing information technologies, in using COTS products effectively, and in assuring security. Today, a DOD strategy to promote interoperability exists, resting on the development and promulgation of technical standards such as the Joint Technical Architecture, the extensive use of middleware, and the evolution of a broader, enterprise-wide, common infrastructure.
|
From page 110... ...
and how that information must flow between parties to support military operations. At the same time, the committee believes that the universe of all possible military operations is simply too large for a single Joint Operational Architecture to be developed successfully, and thus prospects for progress through a single DOD-wide operational architecture effort comparable to that of the Joint Technical Architecture are doubtful.
|
From page 111... ...
System architectures must deal with the issues of boundaries of trust and configuration controls relevant to that system. Operational architectures are intimately related to security because they specify information flows, and help identify those mission-critical functions for which information flows must be assured even under conditions of threat.
|
From page 112... ...
Indeed, one person from that office argued that a major problem was that the definition of C4I technology and systems was porous enough that program managers could argue that they were not subject to directives applying to C4I systems. Given that even with a formal process in place, Joint Technical Architecture compliance remains a major issue, the committee has concerns as to how system and operational architectures will be used.
|
From page 113... ...
This market share, combined with other forces, attracts developers of middleware and applications that are of great potential value to DOD in C4I applications. A simple, but important, example that the committee observed in its field trips was the large number of office software suites for word processing and presentation graphics being used as part of the command and control process and providing important information flows.
|
From page 114... ...
Present efforts in the DOD interoperability strategy suffer from a number of weaknesses: · More must be done to prioritize interoperability needs and make the problem more manageable. DOD efforts to construct a single Joint Operational Architecture are tantamount to specifying the information needs and requirements for all operations that the DOD believes it will have to conduct in the future.
|
From page 115... ...
The committee believes that a good organizing principle is that "proper" would be defined as a scope of analysis and concern that has operational significance, that is inherently joint, and that involves multiple systems. The same arguments apply to data standardization efforts and to the selection and use of tools that enhance data interoperability.
|
From page 116... ...
Data interoperability standards referenced in the Joint Technical Architecture, such as the Defense Data Dictionary System, are mandatory defense-wide. But commercial experience suggests that because successful data models are based on an understanding of the interfaces in a system and how those interfaces are to be used, data models are more properly tied to operational and system architectures.
|
From page 117... ...
Recommendation I-1: The Assistant Secretary of Defense for C3I and the Joint Chiefs of Staff should complement the DOD's current broad interoperability strategy with focused efforts in limited, operationally important domains, to include the development of Joint Operational and Joint Systems architectures for these domains. The committee believes that it is more feasible to develop operational architectures developed for particular joint missions or tasks, organized around either significant operational capabilities or mission slices.
|
From page 118... ...
One mission slice for which this is true is theater air/ missile defense, an area that is highly significant operationally, is associated with serious force integration issues, and not least has substantial operational and system architecture work already done by the Joint Theater Air Missile Defense Organization (operational architectures) and the Ballistic Missile Defense Organization (systems architectures)
|
From page 119... ...
Again, the consideration of available foundational work is important and suggests that a candidate would be a collaborative Toint 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.3~ 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.
|
From page 120... ...
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.
|
From page 121... ...
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)
|
From page 122... ...
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~.
|
From page 123... ...
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)
|
From page 124... ...
· 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.
|
From page 125... ...
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)
|
From page 126... ...
Given the Defense Information Systems Agency's Joint Interoperability Test Center's role in testing compliance with the Joint Technical Architecture, it is appropriate
|
From page 127... ...
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)
|
From page 128... ...
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.
|
From page 129... ...
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.
|
Key Terms
This material may be derived from roughly machine-read images, and so is provided only to facilitate research.
More
information on Chapter Skim is available.