C4ISR for Future Naval Strike Groups (2006)

The Navy is starting down the path of creating a capabilities-based force. This approach to defense planning imposes a general requirement on the Navy’s command, control, communications, computers, intelligence, surveillance, and reconnaissance (C4ISR) systems to be able to adapt rapidly to the actions of agile, improvising adversaries and to the demands of changing U.S. objectives. For example, engagements might oscillate between warfighting and peacekeeping activities; correspondingly, the specific configuration in which ships participate in these activities may change from one deployment to the next, or even within a single deployment. This need for adaptation implies the need for flexible systems that provide the following:

• The capability to serve users with available intelligence, surveillance, and reconnaissance (ISR) information that suits their specific operations (it could involve both direct connection to the appropriate information sources and the preprocessing of information by others to support operational use).

• Reconfiguration capability for integrating command-and-control (C2) applications to fit the revised work flow in which a naval strike group is engaging.

• The ability to insert available new technology that could help to adjust existing operational capabilities so as to better match the specific activities of adversaries and the current objectives of U.S. efforts.

• Support for the dynamic integration of ad hoc peer groups that connects software applications and users and that permits new information flows with a considerably higher level of data integration than is found in current systems.

These needs demand that the Navy’s C4ISR systems support not only interoperability (both joint and within the Navy)—which is the current Navy emphasis on transporting information coherently between machines, that is, the ability to share information to enable cooperative action—but also composability and adaptability, which this committee defines as follows:

• Composability—the ability to create new work flows dynamically by reconfiguring the integration of existing subsystems to serve current operations and, in the longer term,

• Adaptability—the ability to rapidly augment and use existing subsystems for missions for which they were not originally intended.

The achievement of composability and adaptability requires interoperability, but in a form that goes beyond currently envisioned interoperability initiatives.

A major objective of the new naval strike group construct is the ability to assemble and employ tailored capability packages to make optimum use of limited resources in circumstances involving simultaneous, ambiguous, and dynamic operational contingencies. Being able to meet this objective implies the availability of organizational and behavioral attributes that can be addressed in terms of composability and adaptability as defined above. Achieving this transformational capability demands an architectural foundation—including operational, technical, and system views—that is supported by a mature, robust, scalable, self-managing, and network-centric information infrastructure. Composability embraces entire strike groups, individual platforms, systems hosted by platforms, and combinations of components and functions within systems; composability is to be used at the operational as well as the tactical level of war.

Navy goals require composability both at the operational and the technical architectural levels. Operational composability is the ability to combine units and resources into tailored packages possessing specific capabilities for particular missions or tasks. This process happens in the context of an organizational hierarchy in which a given level can be decomposed into the entities at the next lower level and a tailored package can be composed from those entities. A representative hierarchy is as follows:

• Enterprise (e.g., joint task force),

• Subenterprise or community of interest (COI),

• Node or platform,

• System,

• Subsystem, and

• Component.

Thus, for example, system and subsystem capabilities can be tailored by integrating various combinations of components; nodes can be tailored by hosting various systems; enterprises or COIs can be tailored by combining nodes; and so on.

At the technical level, achieving this operational composability requires that the entities in a hierarchy possess a set of properties that enable the operational composition. These properties include managed interfaces, both vertical and horizontal; consistent data models; consistent instantiation appropriate to the level of the entity; consistent concepts of operations (CONOPS) and allocation of responsibilities; and consistent provisions for sustainment and resource management.

Together, the information system architecture that integrates software subsystems and the specific designs for individual software subsystems will play a major role in determining how well the Navy can meet its composability objectives. The Navy is facing the issues required for creating flexible systems; so also are commercial companies, competing with each other for advantages offered by more rapidly exploiting the available information technology components into business systems that provide more efficiency or better customer access.

This commercial objective has led to the emergence of concepts and corresponding commercial initiatives to develop support software for creating more flexible systems. Service-oriented architectures (SOAs) and composable architectures (CAs) are the concepts that have been set in motion by commercial demands, and within these architectures, concepts have been developed for an Enterprise Services Bus (ESB) for assembling services within a standard framework. An important aspect of the ESB is that physical network connections are abstracted to permit varying physical arrangements without requiring the development of new software.

ESBs can come in many forms, including those resulting from research focused on the dynamic creation of network overlays. Overlays can be created via the use of protocol suites that run at a system level that is between the software application layer and the network layer. Overlays permit logical connections between software applications designed to exchange information that needs to occur transparently across a diverse set of networks (e.g., Internet Protocol, version 6 [IPv6], [IPv4], ad hoc mesh networks). As a result of adding overlay protocol software as an application interface, a peer group for information exchange can be formed without the need for new software. For example, such a peer group might connect users tied to a mesh network with information derived from a network of unattended sensors and with information derived from a remote IPv6 network of computer applications. Another set of commercial initiatives is dealing with data integration and semantics, to include advancements in information standards that provide information about the relationships between different data items.

All of these concepts are built on specific approaches for decomposing a system into subsystems so that they can be integrated flexibly to achieve

composability and adaptability objectives, and on the pursuit of open standards to support implementations. As indicated in Chapters 3 and 4, the Department of Defense (DOD) has chosen an architectural path that runs along the same lines as those of the commercial efforts, with the objective of being able to use commercial off-the-shelf (COTS) products to implement its architectures.

The move by the DOD to SOAs is motivated in part by compatibility with commercial best practices. It is important to note, however, that this is a fairly new trend in commercial technology, and few systems of the scale needed by the Navy for C4ISR for strike groups have been developed thus far. Systems engineering for the computing needs of requirements-driven system design is a relatively mature field; but building interoperable, and later composable, service-oriented systems is still somewhat in its infancy. There is great promise in this latter approach, but there are still many lessons to be learned through experience in applying these technologies.

For traditional systems development, contractors can draw on a long history of procurements in which the design approaches have been relatively stable—while the computing technology has been rapidly maturing. Reference architectures, open-systems practices, and layered-architecture designs are available as the starting places for new systems development, and object-oriented design has been the dominant paradigm in software development for over a decade. Service-oriented computing, on the other hand, is significantly newer; it is just coming into its own in both software development and systems design. Even the commercial standards in this area, such as the SOAP, WSDL, and UDDI language,¹ are currently under revision within various standards organizations, with considerable debate ranging over the paths for their evolution.

As the DOD, and in turn the Navy, go down this path for achieving flexible systems, a number of unknowns with respect to this technology must be managed as part of the plans for system evolution. These unknowns are of concern in the commercial world as well. But owing to the scale and the critical use associated with many of the Navy’s systems, they can potentially be significant obstacles to successful use and must be treated accordingly. These areas include the following:

• Experience-based methodologies for managing and implementing SOAs do not exist. The Navy will need to learn while doing.

• The reliability of system services depends on the reliability and availability of the components that comprise a given function. If a variety of existing subsystems are newly integrated, (1) new software bugs may be exposed, (2) new performance demands may become manifest, (3) new user errors may appear owing to a new use of an existing user interface, (4) new error conditions may emerge (e.g., existing capacity boundaries may be exceeded with a new application of existing subsystems), and so on. In addition, the various service providers’ hardware suites may not provide the integrated availability needed for the newly integrated application. Experimentation with new techniques for assessing reliability will be needed.

• The required security levels and corresponding defense mechanisms for newly integrated system services will depend on a number of issues. These include (1) the actual use and users of new subsystem integrations, (2) the elements that are integrated to perform the new functions, (3) the capabilities of adversaries to exploit vulnerabilities, (4) the perishability of the value of information derived via the new integration of subsystems, (5) the extent of the applicability of newly derived information to multiple aspects of an engagement, and so on. These are largely unexplored issues in SOA development. (Security is further discussed in Section 5.3.)

• The DOD will be building some of the largest-scale SOAs developed to date. However, best practices will need to be developed for enhancing the scalability properties of these architectures for larger and larger applications involving larger numbers of users, sensors, and software applications with respect to bandwidth, network management, information caching and replication, and other such metrics.

• The Navy strike force methods of deployment will require the development of CONOPS for ad hoc teaming arrangements. These arrangements might include different Navy units, Navy and joint or national assets, or Navy units and coalition allies, to provide functional teams that can respond to evolving situations as required in the field. This need for ad hoc teaming arrangements involves addressing the type of technical support that would be needed in the field in order to exploit the values of SOAs and CAs.

In addition to managing the areas listed above, integrating legacy systems into the new flexible architectures will be a difficult and expensive problem to solve. The commercial world will be dealing with this problem, just as the DOD and the Navy will, for the foreseeable future.

In the commercial world, each enterprise has had to develop its own strategy for managing the integration of legacy systems, depending on numerous factors. These include (1) the potential importance of the legacy system in the overall

SOA scheme of things (number of users, number of uses, criticality of uses, and so on); (2) the cost to replace the legacy system; (3) the reliability of the legacy system and the maturation time for a replacement system (and possible dual system operations); (4) the ability and cost to replace current operators and support staff or to train replacement support people and operators.

Similarly, the Navy should develop its own strategy for managing the risks of being able to integrate legacy systems practically into the newer and more flexible architectures. It also needs to be more willing to decide to end the lifespan of a legacy application that cannot participate in SOAs and to develop new, more-maintainable and -extensible versions.

The vast majority of the C4ISR systems in the field today will still be there more than a decade from now. The C4ISR systems currently planned for fielding in the next decade must be able to interoperate and have data-compatibility with legacy systems. Traditionally the solution has been to apply a separately developed appliqué, sometimes called middleware, that translates the information from one system to another. Unfortunately, the development of the appliqué frequently takes significant resources, is system-unique, and takes a long development time to implement. What is needed is an independent parser of message information that can facilitate the recombination of information into different message formats as well as feed information databases for other applications.

By focusing on the information in a message rather than on its format, the Navy can obtain synergistic benefits from existing and future C4ISR programs. Current message-exchange principles encompass homogeneous product exchanges, including transmission via frequency modulation voice, tactical data links, text files, messages, and e-mail. The data-exchange environment utilizes a vast set of data link protocols and data item descriptions that are unique to each domain. There are few common functions. Each entity maintains separate documents and applications relevant to its battlefield, functional area, or designated mission. Sensors provide critical red (opposition), blue (friendly), and gray (neutral) force data to allow fleet units to accomplish their missions.

A critical need exists for technology advancements in communication and information-exchange architectures to eliminate the shortfalls associated with a message- or protocol-based level of information systems interoperability. Data links and message-based exchange typically result in challenges associated with managing message transmission; these challenges include protocol formatting, communication device overhead, limited bandwidth, nonstandard data definitions, inconsistent data protocol implementation, and message contention. A construct is needed that receives messages based on protocols, extracts the information content, then intelligently routes the information on the basis of its content and the applicable routing rule set.

One possible approach to addressing information exchange with legacy systems is presented below. For the example approach, two key technical enablers

are required: a protocol abstraction layer (PAL) and a protocol description language (PDL). The PAL would be an applications program interface (API) that enables using applications to query for the existence of a new protocol at runtime and then to decode and encode messages correctly on the basis of this protocol.

The key to implementing the specific protocol-encoding-and-decoding scheme is through the PDL. The PDL would be a high-level-format grammar that allows a communications engineer to describe in sufficient detail the implementation of a new protocol without requiring low-level programming. The PDL environment would then translate the description into a (Windows DLL or UNIX) library that meets the PAL API standard, thus allowing the PAL-enabled application to detect, encode, and decode the data automatically from the link. The development of the PDL should be in a simple, user-friendly language in order to be implemented in a fleet environment by trained personnel rather than by engineers at a company that develops software. The purpose of a PAL is to contain a common set of function calls and to isolate the protocol from the application. The PDLs would be maintained in a protocol registry that would interface with the PAL.

The information parser based on the simple but unique PDLs feeds a database or feeds a PAL that takes the information and formats it into another message for retransmission. Legacy systems can then interact with developmental systems. Additionally, operators with access to the database of information fed by a variety of sensors can use that access to develop new and campaign-specific data-fusion products. These products cannot be envisioned during the long development cycle of individual C4ISR systems. Interoperability requirements in the developmental process are frequently seen as burdens. The acquisition of a separate entity not tied to individual systems and with which systems would be required to interact (in a simple manner) would permit the continued relevancy of legacy systems as well as facilitate the inclusion of future systems.

In order to succeed in the development of the new architectures and the use of needed support technologies (both already-existing and emerging technologies), the Navy should undertake a broad range of initiatives. These include both technological and systems-management initiatives. Subsection 5.2.2 discusses a set of important steps that are recommended for the Navy in order to gain the advantages of flexible architectures and to manage the attendant risks of adoption.

Further, it is critical that the Navy develop a process by which lessons learned, best practices, and “how to” knowledge for SOAs can be developed and maintained, leading to the eventual development of comprehensive reference architectures for SOA-based system development and evolution. This is particularly true for Navy-specific C4ISR systems (e.g., undersea warfare [USW] systems) that are less likely to be duplicative of joint efforts in this area. Collecting this information and developing such reference architectures should be part of the

job responsibilities of the Navy Chief Engineer discussed in Chapter 3, and in any case should be a responsibility of the Assistant Secretary of the Navy for Research, Development, and Acquisition (ASN[RDA]) organization.

The redesign of Navy forces into the more dynamic strike forces described earlier requires that Navy force components be able to form ad hoc teams—teams both organic to the Navy and in tandem with joint or coalition assets. The time available for this teaming is anticipated to become shorter over time, with current goals of having extremely rapid composition of forces (new components joining existing ones during operations) as a robust capability by the 2020 time frame. Current practices can require weeks to months for component-level integration, well beyond the time frames envisioned in next-generation Navy strike operations.²

Figure 5.1, for example, is based on a study of the time taken at the Army’s Communications-Electronics Research Development and Engineering Center (CERDEC) for the development of the critical work flows developed to support Army and Marine Corps systems in preparation for Operation Iraqi Freedom. Despite 6 months to prepare, some work flows were unachievable, particularly those requiring interoperability between Army and Marine Expeditionary Unit (MEU) C2 systems. Even some relatively simple compositions, for example between the Corps and division level for blue position information, took more than a month to develop and test, and included “swivel-chair” integration (a person moving information between one set of systems and another) to handle security concerns. Clearly such times are not commensurate with the time frames envisioned by the Navy for future operations.

It is the opinion of the committee, based on its assessment of commercial needs and technology developments, that composability for ad hoc teams at the level needed for Navy operations will not be a sufficiently mature technology for Navy application without a targeted research investment such as that called for in Chapter 4. This is because, while the business world does have need to configure its systems more rapidly than in the past, there is little commercial equivalent to the sort of military ad hoc teaming discussed here—teaming that will be required when, for example, a coalition ship joins a Navy surface action group (SAG) to provide some specific intelligence need during a short-term threat and then departs following the dispatch of the mission. While industry

FIGURE 5.1 Operational example: integration by the U.S. Army CERDEC/CTSF Operation Iraqi Freedom. NOTE: OPS, operations; INTEL, intelligence; CFLCC, Coalition Forces Land Component Command; C2PC, command and control personal computer; GCCS-A, Global Command and Control System-Army; ASAS-L, All-Source Analysis System Light (Army intelligence workstation); ASAS, All-Source Analysis System; MCSL, Management Control System-List; SQL, Structure Query Language; UID, user identification. SOURCE: ISX Corporation with the University of Maryland. 2004. Assured Integration on Demand to Support Improvisation Workflows: DARPA Semantic Enabling and Exploitation (SEE) Seedling Effort, Final Technical Report CDRL A007, College Park, Md., July 29, Figure 4, p. 8.

will be quick to adopt and extend composability methodologies, these are not currently a matter of significant investment outside the research world. The research that is currently being done in reliable composable systems is being carried out under the rubric Semantic Web Services, under the funding of the European Union’s Information Science and Technology (IST) program, with little matching U.S. investment.³

As discussed earlier, adaptability is the longer-term goal of exploiting composable systems to function in roles for which they were not originally intended or designed and also to respond to dynamic, especially unanticipated, events in a fashion that optimally applies their capabilities to achieve goals.

System-level adaptability (i.e., automated reconfiguration and adaptation on demand) is an exciting research-level capability. However, the committee does not see this as a reliable, large-scale, automated capability by the 2020 time frame, even with the continuation of current DOD and non-DOD research investment in adaptable systems. Some amount of adaptability, especially within system subcomponents, is likely to be available in practice by that date. However, a semiautomated, human-in-the-loop ability to configure systems rapidly on the basis of the composable systems practices discussed above will allow Navy strike groups to have significantly greater flexibility than they have now to perform new and rapidly changing missions, especially in littoral or combined open-ocean and littoral operations. Achieving this level of semiautomated adaptability, used as a target capability in the design of composable architectures, will help to focus the development and deployment of composable service-oriented architectures.

Security is a mixture of policy and technology derived from a risk assessment that accounts for vulnerabilities in the context of system use cases. The security implication of composability and adaptability implementations is as follows: all vulnerabilities cannot be known in advance since they vary depending on the specific combinations of components to be integrated, and all risk-taking parameters cannot be known in advance since they are determined by the value of integrating specific new system capabilities to deal with specific use cases. As a result, a system function is needed that provides the capability to reconfigure security features (authentication, authorization, multilevel security (MLS), assurance of data integrity, protection of sources, and so on) to match the situations that drive reconfigurations. This system function must deal with establishing procedures as well as technology. The commercial efforts to deal with security will not be driven to the same limits that the needs of the DOD and the Navy require.⁴ As a result, DOD research efforts must fill this need. The Navy needs to be concerned about this area of activity for several reasons:

• Navy assets will be part of configurations established by others. The Navy should assure itself that these configurations are suitably protected relative to normal Navy uses.

• The Navy will be interested in using other Services’ C4ISR systems and must be sure that the security policies are not overly inhibiting and that Navy users are prepared to operate in the required manner.

In and of themselves, service-oriented architectures do not solve the information interoperability and data-sharing needs of current and evolving Navy C4ISR systems. However, SOAs do open up new opportunities for these capabilities, as the separation of data and computation allows far greater flexibility in information exchanges. The key enabler of this separation is that of using metadata. Using metadata provides new levels of flexibility by separating data design and modeling (what the data are used for) from database and system-level considerations (how the data are stored).

Metadata is growing in importance as a technology for enabling data interoperability and new information flows in system-of-systems configurations. Currently, Extensible Markup Language (XML) is primarily used in system-to-system interoperability to carry the content of messages, or at least the headers. It is one way of abstracting and documenting what programs produce as output and what it is expected that they will receive as input. To save space and keep bandwidth down, it is customary to be able to abbreviate terms such as legal date of birth to ldb. In XML, this is usually done by creating a document type definition (DTD) or schema, allowing an XML parser to know that the short version is an abbreviation for the official term. Where multiple systems can share the same DTD or schema, multiple terms or names can be used, allowing further interoperability.

Current work within the Navy and joint communities is exploring the use of some of these capabilities. For example, XML schema datatypes (XSDs) are being developed to provide descriptions of data elements in various systems, and XML schemas are being developed to provide greater interoperability. Commercial initiatives, however, are viewing these activities as part of a longer-term data-engineering activity, providing greater semantics for allowing more composability of data resources via new languages such as Resource Description Framework (RDF) and Web Ontology Language (OWL), and new Web-service description capabilities (WSDL 2.0, Web Ontology Language for Services [OWLS]) that go beyond current metadata efforts in the DOD.

These new technologies, based on the RDF and its ontological extension OWL, extend metadata capabilities to provide greater machine-to-machine automation with respect to information exchange. They also begin to provide a framework in which the composition of systems, not defined a priori to work together,

can develop information exchanges with significantly less, and eventually no, human interaction. An ontology defines the terms used to describe and represent an area of knowledge. Ontologies are used by people, databases, and applications that need to share domain information. (A domain is just a specific subject area or area of knowledge, such as medicine, tool manufacturing, real estate, automobile repair, financial management, and so on.) Ontologies include computer-usable definitions of basic concepts in the domain and the relationships among them.⁵ The ontology permits logical inferencing to link data items that would otherwise not be obviously connected. For example, a computer system can determine from an ontology that “A” is related to “B” and that “B” is related to “C,” so that it could infer that “A” might also be related to “C.” Ontologies encode knowledge within a domain and also knowledge that spans domains. In this way, they make that knowledge “reusable.”

OWL became an industrial standard (a recommendation of the World Wide Web Consortium) early in 2004. It is based on the DARPA Agent Markup Language (DAML) developed by the Defense Advanced Projects Agency to specifically address the interoperability needs of military C4ISR systems. OWL also is aimed at providing a richer form of metadata, which can be used to allow nontextual information (such as imagery and streaming video products) to be annotated in ways to enable more rapid and precise content-based search, with tools for this search currently starting to transition from basic research to technology development.

Other extensions to metadata that are being observed in the research world include the development of languages for the expression and exchange of business process rules, work on declarative frameworks for expressing information-access policies based on the nature of the underlying information and/or the current role of the entity accessing the information, and more-automated extraction of content from data (data mining and data discovery) in system- and data-independent ways. It is likely that these technologies will be in wide use by 2020. Current Navy and DOD efforts, primarily focusing on short-term XML needs, will likely need to be extended to explore and exploit these new and emerging technologies for greater data integration and information exchange.

The Navy C4ISR system is highly distributed. It depends on timely communications between components in order to achieve time-sensitive performance

requirements. For a predetermined arrangement of software and hardware components, it is possible to evaluate response times versus performance needs, and the portion of the time budget allocated to communications. However, for SOAs there may be configurations that are not known in advance for which communications performance requirements are stressing. This possibility points to the need for gathering measurements on time utilization at the service architecture’s component level, so that integrated performance of new configurations can be determined in advance of use.

These measurements can be built into the system and gathered through a history of past usage. When integrated into a suite of performance models that can be part of the support environment for an SOA, results can be developed that anticipate performance. In particular, sophisticated communications-systems models exist that can be used to evaluate delay times on a mission-specific basis. When combined with models for deriving sensor delays, computational delays, and user input/output delays, an overall assessment can be made on communications needs and the adequacy of existing capabilities for specific new applications of the SOA. In order to achieve this kind of capability, the Navy must make embedded measurements and performance models a part of delivered systems; these embedded measurements and performance models would be used over the lifetime of the system to anticipate performance issues that would arise with new SOA configurations.

The traditional Navy processes for developing and supporting C4ISR subsystems are not well aligned with the pursuit of SOAs and CAs or with establishing composability and adaptability requirements on C4ISR subsystems. This section discusses these misalignments and their consequences. The discussion will serve as the basis for a number of the recommendations in Section 5.7.

Prior to discussing current Navy processes, examples are provided of what one would need to address in designing C4ISR systems for composability and adaptibility. Supporting an architecture to address adaptability and composability would involve, for example:

• Providing multiple levels of data quantization, image compression, and refreshment rate from a sensor—each selectable on a use-case basis;

• Providing access to data at stages prior to complete processing so that fusion possibilities can be varied on a use-case basis; and

• Configuring a hardware design so that capacity, performance, and segregation of information can be adjusted on a use-case basis.

In order to develop C4ISR subsystems that will be productive elements of a

service-oriented or composable architecture, the Navy needs to assign new efforts to be carried out by its development community, its research community, its operational community, and its system support community.

Currently, the Navy will typically initiate the development of a new C4ISR system (for the purposes of this report, a new subsystem, to become a part of a broad array of C4ISR subsystems to be integrated as an overall system, i.e., a system within a system-of-systems) by executing a rigorous system requirements process. This process deals with aligning operational needs with the new subsystem’s technical requirements. The technical requirements for the new C4ISR subsystem are dissected into (1) the identification of needed subsystem functions; (2) the derivation of the subsystem’s functional performance requirements; (3) the integration standards that must be satisfied, both for internal design purposes and for external system interoperability; and (4) the needs regarding overall subsystem reliability, security, testability, supportability, and so on. Based on this set of requirements, the new C4ISR subsystem’s design is derived, including a hardware/software architecture, a selection of specific hardware components, and a delineation of needed software components. The hardware and software are subdivided into COTS-available components and custom-developed components, and development is managed on the basis of the results of the various planning efforts. When one relates this process to the pursuit of SOAs and CAs, the following become apparent:

1. There currently is no feature used by the Navy related to composability. That is, there is no effort to determine how the new C4ISR subsystem might be designed so that it might also be suitable for other than the specifically planned uses considered in the requirements analysis and therefore might better fit into a higher-level SOA or CA (the so-called system-of-systems architecture).

2. Similarly, there are no Navy test plans that evaluate the ability to use components from the new C4ISR subsystem in work-flow configurations or ad hoc missions that were not specifically designed for.

3. In turn, there are limited acquisition-evaluation criteria (metrics) that have been developed to deal with items 1 and 2 above, that can be used by both contractors and procurement officials as a basis for determining a successful development effort. The use of requirements generated through the network-centric operations and warfare reference architecture is an initial step that can be expanded to address this need.

4. Standards are a critical part of achieving interoperability (and therefore composability and adaptability), and the Navy should ensure that the standards stay current as new standards emerge and existing standards age out.

While standards for interoperability might ensure that components can be integrated, they provide no assurance that either the software or hardware components for a specific C4ISR subsystem have been selected to enable flexibility of use. Furthermore, the Navy tends to tie the hardware and software that constitute a C4ISR subsystem together, so that a relatively stable set of software for a given subsystem can result in very old, and from an integration viewpoint dysfunctional, hardware. Inherently, composability and adaptability call for continuous modernization to allow for insertions of new COTS products (both hardware and software) as readily as possible, as well as to allow for migration to the ever-evolving set of standards that will emerge to support SOAs and CAs. In addition, as time goes on, there will emerge new use cases that the existing architectures will not easily support, resulting in the reconfiguration of C4ISR subsystems on the basis of experience. This experience should include, as outlined in Chapter 3, Section 3.5, a robust set of simulation and analysis activities and regular hands-on tests, exercises, and experiments to verify end-to-end design integrity and robustness, establish realistic bounds on end-to-end performance, and accommodate innovation. This process will require a focal point for integrating experiences into new requirements for the overall SOA and the component C4ISR subsystems.⁶

A significant issue related to the Navy C4ISR subsystems’ being part of an SOA/CA architecture is the evaluation of scale. The potential reconfigurations and the potential concurrent use of assets are related to scenarios that are not known in advance. Since part of the SOA/CA is features that adjust information flows as capacity limits are reached, evaluations must account for how flow reductions impact operations. The fidelity requirements for a useful system-of-systems simulation model would be highly variable, depending on the scenarios and issues being evaluated. It is likely that useful evaluations would require a mixture of live equipment and simulated equipment in the laboratory and field experiments. This likelihood points to the need for the Navy to create a new concept for the evaluation of capacity limits and performance degradation of Navy missions as a function of system-of-systems capacity, performance limits, battle damage, and information warfare. Instrumentation, simulation capabilities, and the use of live components must be orchestrated to support credible isolation of bottleneck components.⁷

While the Navy development community is not yet organized to fully incorporate SOAs and CAs, certain Navy-funded research efforts have started to develop concepts for these architectures (see Chapter 4, Section 4.6). In particular, the Space and Naval Warfare System Command’s Composable FORCEnet activity has identified opportunities involving technology for supporting composability and adaptability. This type of effort requires increased emphasis in order to better prepare the Navy for success. In addition, DARPA has been doing some research in this area as well, but the level of those efforts is also limited.

In addition to the new efforts required of research and development (R&D) communities, the efforts to achieve composability and adaptability require significant efforts from the operational community. There are two aspects of creating SOAs and CAs that are highly dependent on operational inputs. First, a community of operators familiar with the C4ISR system-of-systems is needed. This set of people is needed to fill two critical roles:

1. To provide sets of potential operational use cases that might, over time, arise for the Navy to respond to. These cases would involve the Navy’s using subsystems developed by other Services as well as other Services using subsystems developed by the Navy. The cases would also include joint teams of the Services and allies using a variety of C4ISR subsystems as an integrated capability. These cases are necessary for tangibly evaluating the composability and adaptability of the overall system-of-systems architecture. Additionally, the operational team would be called on to set the evaluation criteria, on a use-case by use-case basis, for measuring the operational responsiveness of the overall architecture. These inputs are critical for providing the basis for generalizing requirements so that designers can design, testers can test, evaluators can evaluate, and resource managers can provide resources.

2. To support the development of a concept of operations that addresses the role that field operators would fill in setting up new configurations, the kind of tools that they would require to provide them control, and the technical support that they would need in order to set up timely reconfigurations.

The discussions above point to rapid insertion of new COTS technologies and the possibilities both for modifying existing software to support new reconfiguration needs and for adding new functions that are responsive to imme-

diate needs. In order to perform these tasks quickly, a specialized support capability will be required that can deal with the full system of systems.

Typically, support teams are formed to address one subsystem and do not have the visibility to deal with modifications that cut across multiple subsystems. A system-support strategy is needed to address this SOA/CA-driven need. In addition, over-the-network software modifications would appear to be a necessity for rapid adjustments. However, with the ability to make quick changes comes the need to develop rapid testing approaches that include regression testing as well as rapid remote-user training for adjustments to user interfaces.

Finding: Emerging threats, the rapid evolution of military and commercial technology, and new concepts of operations—including operations with other U.S. government agencies and ad hoc coalition forces—demand that naval C4ISR systems have increased levels of composability and that they have adaptability.

Composability focuses on the ability to create new work flows dynamically, changing both information flow and resource assignments to achieve mission success. The ad hoc teaming requirement of C4ISR systems for Navy strike forces drives a critical need for composability.

Adaptability is the longer-term goal of using military systems in missions for which they were not originally intended, in response to dynamically changing situations and/or real-time events. Adaptability depends on but goes beyond the needs of composability.

The requirement for composability and adaptability is not unique to the Navy; commercial initiatives such as service-oriented architectures and composable architectures have been developed in part to address these issues. However, there is limited experience in applying these approaches to problems of the scale of naval C4ISR, and relatively little is known about how to specify and test large-scale systems for composability and adaptability, and historically nothing exists about information assurance in this connection. In addition, unique military issues of multilevel security are not being fully addressed in the commercial sector.

Recommendation: The Chief of Naval Research should conduct research and experimentation to develop and gain experience with technologies for composable and adaptable systems.

DARPA has initiated some limited research efforts that address the issues of composability and adaptability under the rubric of agile architectures For example, under the Heterogeneous Urban Reconnaissance, Surveillance, and Tar-

get Acquisition (RSTA) Team (HURT) Program, researchers are developing a system using model-based control algorithms to control a set of unmanned aerial vehicles (UAVs). A challenging problem for the researchers is to demonstrate that they can adapt the system to include a new UAV not in the design set within a 10 day period. Current research efforts need to be expanded and need to address additional C4ISR problem domains. The Office of Naval Research needs to focus on naval C4ISR problem domains, gaining experience with commercial technologies and developing additional technologies.

Finding: The mission flexibility and deployment models for Navy strike groups are crucially dependent on the composability of C4ISR packages at numerous levels of granularity. Commercial emphasis on interoperability helps but does not solve the Navy’s needs for ad hoc teaming.

Recommendation: The Chief of Naval Research should work with the research community to stress the need for composability and adaptability and to mature those technologies for service-oriented and composable architectures that are of special value to the DOD; this needs to be done faster than the commercial world would without the DOD investment.

A starting list of technologies for which DOD-funded research is needed should include security technologies, technologies for establishing ad hoc groups, data-integration technologies, and user-control and interface technologies.

Finding: Models for the development, use, and field support of C4ISR systems that will be responsive to ad hoc teaming needs are currently misaligned with the Navy’s present model of procurement and support of C4ISR systems.

This misalignment relates to development methodology, system-support methodology, and the development of overall concepts of operation.

Recommendation: The Assistant Secretary of the Navy for Research, Development, and Acquisition (ASN[RDA]) should initiate a focused activity to augment current development methodologies so that they account for managing composability requirements in C4ISR acquisitions.

This activity should include the establishment of (1) operational metrics for evaluating the quality of a design, attendant test and evaluation demands, and supporting instrumentation and simulation tools for evaluating scalability; (2) user concepts and tools for managing reconfigurations and technology insertions into C4ISR systems; and (3) field-support needs for making changes, testing changes, and training users on possible new use configurations of C4ISR systems.

Finding: Current Navy procurement models for computer “systems” bundle hardware, software, and applications. This approach will not be appropriate for meeting composability needs.

Emerging trends in computing already embraced by the Navy (network-centric warfare, enterprise service-based approach, in-place software upgradability, Web-based protocols) offer an opportunity to better separate software and hardware upgrades immediately and to move to more rapid hardware and software refreshment rates for the fleet.

Recommendation: To the maximum extent possible, the ASN(RDA) should move to a 4 year upgrade cycle for onboard computing, separating hardware acquisition and C4ISR platform development. In addition, the ASN(RDA) should move to an over-the-network approach for upgrading software on an as-ready basis.

Finding: Data mining needs of C4ISR systems are hampered by a lack of data sharing, (inconsistent) duplication of data in multiple systems, lack of a data “map”—in general, there is a need for data engineering.

Establishing more and more powerful approaches for the use of metadata will continue indefinitely, and XML is not the end. Next steps are already on the horizon, and industry is pushing forward on more developments, particularly including ontologies.

Recommendation: The Program Executive Office for Command, Control, Communications, Computers, Intelligence, and Space (PEO[C4I&S]) should take the lead in the development of a Navy-C4ISR-specific data-engineering activity and ensure that the Navy C4ISR needs are represented in joint metadata activities.