By F. EDWARD BAKER JR. and GREGORY E. MONTEITH

Dr. F. Edward Baker Jr. is the staff systems engineer for the Theater Warfare Systems Department at the Dahlgren Division of the Naval Surface Warfare Center (NSWC). Gregory E. Monteith is the distributed engineering plant program manager at the NSWC's Dahlgren Division.

 
If recent conflicts are any indication, future U.S. military combat operations will continue to be short-duration regional conflicts characterized by highly networked coalition forces operating modern equipment and employing increasingly accurate all-weather weapons. In this complex, dynamic environment, the ability of naval forces to conduct many of their assigned missions will be directly proportional to the level of interoperability achieved among naval and joint forces' combat systems as well as battle-management, command and control, communications, computers, and intelligence (BMC4I) systems. Interoperability is defined in this context as 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 and achieve the assigned mission."

The Navy has been working for decades to optimize the interoperability of its aircraft carrier battle groups (CVBGs) and its amphibious ready groups. Individual systems on today's ships are well-integrated and have been rigorously tested "within the lifelines" of the platform at such land-based engineering facilities as the Integrated Combat System Test Facility (ICSTF) in San Diego, Calif., and the Surface Combat System Center (SCSC) at Wallops Island, Va.

A Family-of-Systems Challenge

While shipboard testing of individual platforms has provided U.S. forces highly capable weapons systems, the ability to design, develop, engineer, and test for the entire battle group's interoperability--a so-called "family-of-systems" level integrating the collective capabilities of all units--did not exist. Consequently, battle group-level warfare system design, development, engineering, test, and evaluation functions could not be performed on newly developed or upgraded systems. As a result, the first time a battle group's new or upgraded combat or BMC4I systems were tested or operated in a family-of-systems environment was during major fleet exercises, predeployment workups, or formal Fleet Operational Test and Evaluation (FOT&E) test periods. Not surprisingly, as new and more sophisticated combat systems and computer programs entered fleet service in recent years, operating forces experienced a growing number of interoperability problems. The problems often were manifested at the worst possible time--as units completed at-sea evolutions during the interdeployment training cycle in final preparation for their next operational deployment.

Difficulties peaked in the autumn of 1997. The Navy was obliged to pull two of its recently commissioned surface combatants from their scheduled deployment cycle. The reason: Their equipment and systems did not provide a reliable and interoperable warfighting capability.

To many informed observers, this turn of events did not come as a surprise. The Department of Defense (DOD) acquisition process is designed to develop and build individual systems. The Navy's program executive office (PEO) structure and budget process also support the development of individual systems. A "stovepipe" approach that served the fleet well historically in the development of individual systems did not necessarily support the development of an interoperable family of systems.

While evidence continues to build that changes in DOD acquisition and budget processes are needed, it was undeniably clear that the Navy itself faced a compelling and immediate requirement to adopt engineering, development, test, and evaluation methods to permit the delivery of proven interoperable systems to operating forces. Engineers and operators faced a major challenge in addressing this need. The operational at-sea environment cannot provide the controlled, repeatable engineering environment necessary to isolate and identify the root causes of interoperability problems or to develop engineering solutions to correct such problems at the battle group's family-of-systems level.

In February 1998, Adm. J. Paul Reason, then commander in chief of the U.S. Atlantic Fleet, stated in a message to the chief of naval operations (CNO) that "... despite admirable efforts ... the acquisition community failed to deliver integrated warfighting capability to our battle groups." In response, the CNO assigned Vice Adm. George R. Sterner, then commander of the Naval Sea Systems Command (NAVSEA), central responsibility for addressing combat systems and BMC4I interoperability problems within the Navy's systems-command structure and with the service's PEOs. Any course of action was to be developed in close coordination with fleet commanders in chief and their staffs.

NAVSEA undertook a number of aggressive initiatives to formulate a methodic and phased solution--all with an appropriate sense of urgency in view of the implications for the fleet's combat readiness. One key methodology focused on capturing the capabilities of advanced networking technologies to link the Navy's world-class infrastructure of engineering facilities to conduct distributed-engineering work at the battle group's family-of-systems level. Netting these numerous and geographically dispersed facilities into a Distributed Engineering "Plant" would enable engineering teams and subject-matter experts to apply systems engineering functions, conduct activities, and test actual combat systems and BMC4I hardware and computer program loads at the overarching system level--all in a controlled, repeatable engineering environment.

Bureaucratic Pitfalls Avoided

To determine the feasibility of this innovative concept, Sterner formed a task force responsible for the distributed engineering network and battle group/battle force interoperability. He charged the group to "determine the feasibility of using a land-based Distributed Engineering Plant and advanced networking technologies to do design, development, test, and evaluation of interoperability at the unit and battle force level."

The task force--composed of senior engineers from NAVSEA, the Naval Air Systems Command (NAVAIR), the Space and Naval Warfare Systems Command (SPAWAR), and their associated field activities--reported its conclusions in June 1998 that a land-based Distributed Engineering Plant, while technically feasible, would be difficult to develop organizationally.

This organizational assessment recognized that the Navy's land-based combat systems and BMC4I engineering facilities were predominantly owned by PEOs and managed by laboratory and field personnel from the various Navy systems commands--all operating with different scheduling and resource priorities.

Despite the potential bureaucratic pitfalls, NAVSEA successfully forged an alliance of NAVSEA, NAVAIR, and SPAWAR field activities--headed by NAVSEA's Naval Surface Warfare Center, Dahlgren Division--to commence the stand-up of the prototype Distributed Engineering Plant in September 1998. The alliance's initial objective was to conduct distributed land-based testing, evaluation, and problem resolution of existing data links and weapons-systems components, such as the Aegis Weapon System (AWS) and the Advanced Combat Direction System (ACDS--installed on aircraft carriers and amphibious ships)--all in a controlled multi-unit environment. The project initially focused on the critical air-defense warfare-mission area.

By leveraging commercial-off-the-shelf communications systems and networking technologies--and through the extraordinary cooperative efforts of the many engineers involved in the project--the prototype plant was established and validated in just four months. By December 1998, the following Navy sites had been linked to interoperate in one extensive network:

• Surface Combat Systems Center, Wallops Island, Va.;
• Aegis Training and Readiness Center, Dahlgren, Va.;
• Aegis Computer Center, Dahlgren, Va.;
• Naval Surface Warfare Center/Software Support Activity, Dam Neck, Va.;
• Naval Surface Warfare Center, Port Hueneme Division, San Diego, Calif. (the Integrated Combat System Test Facility);
• SPAWAR Systems Center, San Diego, Calif.;
• Navy Tactical Communications Support Activity, San Diego, Calif.; and
• Naval Air Warfare Center Weapons Division, Point Mugu, Calif.

A number of critical elements permitted the design and establishment of the Navy Distributed Engineering Plant (DEP), including commercial telecommunication Asynchronous Transfer Mode (ATM) networks, "KG75 Fastlane" very high-speed (ATM only) encryption devices, and Navy combat- system and BMC4I engineering facilities with real hardware and computer- program loads.

Leading-edge, high-speed ATM networks had transitioned from research to initial production offerings in the mid-1990s. ATM services represent the introduction of the next-generation telecommunications and networking technologies. These services provide new capabilities, such as very high bandwidth, scalability, and low latency. Additionally, ATM technology allows for implementation of "Quality of Service" to ensure that the highest-priority users are provided with needed protections as well as "service on demand" as bandwidth and other needs change.

The KG75 Fastlane, introduced in 1997, is scaleable in a range of bandwidths and allows a transition from static bulk encryption and point-to-point links to a dynamic network-centric environment. The convergence of these two technical developments enabled the creation of an ATM network providing encrypted throughput that was several orders of magnitude greater than previous technology permitted--and in a secure-communications environment.

Conceptual Foundation

The concept behind the Navy's Distributed Engineering Plant is not new. It is consistent with the more familiar concept underpinning the Network Centric Warfare approach to warfighting (see Sea Power, March 1999). Network Centric Warfare uses the netting of sensors and weapons systems to permit a distributed force to operate as a single integrated unit--and with a synergistic warfighting capability far greater than the sum of its individual units. Similarly, the Distributed Engineering Plant employs the netting together of actual ship and aircraft hardware and computer-program loads installed at stand-alone design-and-development activities, software-support activities, in-service engineering agencies, test-and-evaluation facilities, and training centers.

This network comprises a distributed family of systems that supports a systems engineering capability that could not be achieved using individual sites. Specifically, the networking of geographically dispersed combat systems and BMC4I systems into a Distributed Engineering Plant has the capability to enable:

• Collaborative design and development of the battle group family of systems;
• Integration of individual systems into the overall battle group family of systems earlier in the acquisition cycle--thereby "engineering-in" interoperability;
• Establishment of a "ground truth" common environment to conduct system and family-of-systems-level testing to isolate faults and resolve problems;
• Distributed battle group systems integration, test, and evaluation in a controlled and repeatable environment with minimal impact on fleet personnel or operations;
• Development of Battle Group Capabilities and Limitations (CAPs & LIMs) documents to help operators--from the battle group commander to the individual console operator--use their unique system configurations to optimum advantage;
• Fleet validation of planned operational tactics, techniques, and procedures; and
• The potential for significant life-cycle cost savings that accrue from testing and evaluating new systems ashore--history has shown that once a system is installed in the fleet, corrective modifications are much more expensive and disruptive.

In January and February 1999, battle group integration tests were conducted using the prototype Distributed Engineering Plant throughout the USS John F. Kennedy Battle Group. These tests were designed to address the Battle Group's capabilities to operate as an integrated fighting force during operational scenarios that required a coherent tactical picture to exercise battle management. Test objectives were specifically focused on assessing the Battle Group's ability to establish and maintain a single track with a consistent identity and commonly held kinematic properties for each object in the battlespace. Additional test objectives assessed the exchange and display of weapons inventory data, conduct of weapons control, force-order processing, the timely exchange of kill assessments, and year 2000 (Y2K) compliance.

During the six weeks of testing, the prototype Distributed Engineering Plant conclusively demonstrated its ability to provide the key "repeatable, controlled environment" needed for the evaluation of the Battle Group's interoperability problems. Although the Navy has conducted land-based testing of individual combat systems, such as Aegis, for over twenty years, this was the first time that a significant number of disparate combat systems dispersed throughout the country were netted together for land-based testing in a battle group environment.

On a daily basis, the prototype Distributed Engineering Plant was able to duplicate key interoperability issues that have been plaguing the Navy--such as track dualing, identification contradictions, and an inability to control and monitor a battle group's engagements digitally. Using the prototype DEP, engineers were able to conduct platform-level "fault isolation" of interoperability problems and evaluate workarounds or fixes to correct many of them. The repeatability feature achieved in the DEP's environment permitted engineers to apply enhanced techniques and procedures to the Kennedy Battle Group's systems to develop workarounds for other system deficiencies. Additionally, fleet personnel were able to use the Plant to evaluate their battle group's operational tactics, techniques, and procedures prior to going to sea.

The versatility of the Navy's Distributed Engineering Plant was demonstrated at the conclusion of the Kennedy Battle Group's integration tests. Over a period of four days following the Kennedy Battle Group's tests, the Distributed Engineering Plant was reconfigured to emulate the deployment configuration for the USS Constellation Battle Group in order to conduct Y2K compliance-testing in preparation for the latter Battle Group's deployment.

Following the Kennedy Battle Group's Integration Tests and the Constellation Y2K compliance-testing, the USS Dwight D. Eisenhower Battle Group was tested in June and July 1999 using the Distributed Engineering Plant. This Battle Group was the first with a Cooperative Engagement Capability (CEC) to be tested on the Plant--and the test results further demonstrated the DEP's ability to contribute to the identification and isolation of fleet interoperability problems. This operation proved, as expected, that the Distributed Engineering Plant's contribution to the battle group performance increases even more as the complexity of the combat systems and data-link configuration increases.

Testing of the USS George Washington Battle Group has recently concluded; the USS Abraham Lincoln and USS Harry S. Truman Battle Groups are scheduled for both Battle Group Integration Testing and Y2K testing early this year.

In addition to the integration testing of battle groups, the Distributed Engineering Plant is presently being used by Aegis Weapon System software engineers to upgrade Aegis operating systems, and by the CEC program office to conduct hardware-in-the-loop testing in preparation for development and operational tests.

"A Resounding Success"

The Distributed Engineering Plant provides a comprehensive family-of-systems test environment to assess the interoperability of the ships and aircraft of a specific battle group before new or upgraded systems are introduced to fleet units. Fleet readiness is therefore markedly improved, with interoperability issues identified and resolved ashore before a battle group gets underway. Once at sea, the battle group can put its new system capabilities through their paces well before an overseas deployment. This allows more time for the warfighter to conduct operational training vice spending time correcting interoperability problems during critical at-sea operations.

Additionally, the results of distributed engineering analyses provide an early and more accurate view of system capabilities and limitations--all of which can be documented in detail. User-friendly CAPs and LIMs documents may then be used as guides for tailoring link architectures and training programs. Processes can be developed to mitigate any problems identified.

Senior Navy officials say the Distributed Engineering Plant has been a resounding success since its inception. The Navy's program engineers responsible for engineering combat systems and BMC4I immediately recognized the potential for additional applications of this family-of-systems system-engineering tool. As a result, demand is rapidly approaching seven-days-per- week utilization. Nonetheless, the Distributed Engineering Plant must still be considered a work in progress. It currently functions with "perfect" connectivity in an open-ocean environment without land-masking weather or other environmental effects. However, to more closely replicate and simulate the fleet's actual operating conditions, radio-frequency degradation, ship pitch and roll, and environmental effects still must be introduced. Adding these other factors to the equation will be a challenge.

The near-term benefits and the future potential of the Navy's Distributed Engineering Plant have already been established in a wide range of diverse engineering analyses. However, the real future of distributed engineering extends beyond any single service. Key warfighting missions such as Integrated Air Defense and Control of Joint Fires are clearly joint missions that will require extensive interoperability among a wide range of multiservice systems. Developing, engineering, testing, and evaluating these systems on a theaterwide level of interoperability will be critical if the United States is to employ its sensors and weapons to their fullest capabilities. Studies are in progress--under charter from the Joint Chiefs of Staff and the Office of the Secretary of Defense--to examine options for the establishment of a Joint Distributed Engineering Plant.

The employment of distributed sensors and weapons in a network-centric warfighting architecture promises to change naval operations on a level comparable to the transition from sail to steam and/or the introduction of carrier-based aircraft to fleet operations. The Navy's entire concept of operations will change, and the impact on joint operations will be equally dramatic.

The technology is at hand to support this quantum shift in warfighting capability, but the Navy must now make the complementary shift needed in its engineering as well as test and evaluation processes. The Navy's Distributed Engineering Plant is truly a paradigm shift in the way a battle group's systems are designed, developed, tested, and evaluated as the group prepares for deployment. As such, it represents the linchpin in the Navy's continuing efforts to achieve seamless interoperability at the battle group's family-of-systems operational level.