With the collapse of the Soviet Union, the U.S. Navy’s battle space shifted from open ocean to littoral and inland operations. New challenges emerged—swarm boats, land-launched sea-skimming anti-ship missiles, uncertain tactics of paramilitary operations—and in the cluttered sea-land interface, reaction time grew more critical.

Yet the Navy’s sensors, computer command-and-control systems, and weapons employment remained optimized to win the Cold War. The ability to rapidly seek out new technology and integrate it into existing warfighting systems was limited, both by defense procurement practice and by aging monolithic software design.

NCW, where sensor information and weapons can be integrated across high-capacity seamless networks, became a necessity. Achieving it across all of the nodes of the joint architecture, however, was problematic with the closed, tightly coupled computing systems of the platform-integrated combat systems.

Against the backdrop of these battlespace changes, another revolution was occurring. Information technology exploded in the business sector, seizing the leadership of computing technology from DoD and placing it firmly in the hands of commercial industry. This had two profound effects:

• DoD no longer could demand characteristics and capabilities in computing technologies optimized to its needs.
• The carefully developed and tailored infrastructure that supports the legacy DoD information environment became increasingly more expensive and less reactive to user needs.

The commercial sector has taken hold of information technology and is driving it at a breathtaking pace—in large part because it has embraced open system standards and architectures. The business base that has emerged dwarfs the DoD acquisition influence, and the gap is widening. The net effect is that virtually all the tactical data and software based weapon systems of U.S. Navy ships and aircraft are unaffordable to maintain, much less upgrade.

Open Architecture

Essentially, open architecture is a new approach to acquiring and managing software components, taking advantage of standards-based computing technologies from the commercial off-the- shelf market. It depends on coordinated implementation guidelines and instructions and the use of widely accepted and available specifications, standards, products, and design practices to produce systems that are interoperable, easy to modify, and extensible.

None of the Navy’s premiere integrated combat systems conform to open architecture today. They all are heavily reliant on the DoD-specific tactical information standards of the Navy Tactical Data Systems Model 4 (LINK 11/M series data message standard) or Model 5 (LINK 16/J series data message standard). They also were optimized for “platform-centric” integration and weapons employment and continue to have archaic software structures.

There are, however, two shipboard systems advantageously positioned to support transformation to open architecture and a common network interface that allows for limited introduction of closed computing systems. They are:

• Aegis Baseline Seven (for guided-missile cruisers and destroyers)
• Ship Self-Defense System Mk 2 (for aircraft carriers and LPD and LHD amphibious ships)
• Common Network Interface (for LHD and LHA amphibious ships)

The Navy faces a daunting task in transforming its high-fidelity sensor, command and decision, and weapon fire control software-based capabilities into open architecture. It requires two distinct, but overlapping, processes:

• The Open Architecture Transformation Road Map, a temporary process that will take the Navy to an initial open architecture condition by 2008
• The Rapid Capability Insertion Process/Advanced Processor Build (RCIP/APB), to provide the agile modernization structure to allow for new capability insertion for the future

The Open Architecture Transformation Road Map is targeted to uncouple software from hardware reliance for capital ships and aircraft by fiscal year (FY) 2008. It is built on five foundation elements:

• Harnessing Future Platform Development. DD(X) is uniquely positioned in its development to produce many of the modern software application based capabilities on a timeline in step with the open architecture transformation objectives. As such, it provides early off-ramps of software applications for use in migrating in-service ships and aircraft to open architecture.

• Using Joint Track Management. Alignment of the sensor, command-and-control, and fire control relationship to the top-level open architecture functional architecture is a must. It is essential for open architecture migration and critical to joint interoperability and the establishment of conditions for “common reuse applications.” The Navy is in partnership with the Joint Single Integrated Air Picture Systems Engineering Organization to develop an Integrated Architecture Behavior Model that defines the critical design elements to be incorporated in the applications of “common services” and vehicular track establishment, management, and identification.

• Establishing Open Architecture Functional Architecture Migration. This element supports the uncoupling of hardware and software and furthers the migration of software boundaries in command and control to align to the open architecture functional architecture. It is being done initially by modernizing the command-and-control and self-defense weapons capabilities resident in the Ship Self-Defense System Mk 2. This system was chosen as the integrated backbone for this migration because of its hardware conditions and, most important, because its command-and-control capability already is organized in a modern functional architecture condition, including its reliance on track management software.

• Mitigating Transformation Risk. Future ship participation in the Open Architecture Transformation Road Map resurfaces here as the Littoral Combat Ship (LCS). The Navy’s approach to LCS is revolutionary for several factors, including its rapid development schedule and modularity. It is an inviting participant in the open architecture effort, both in risk reduction and in bridging software capability migration between DD(X) and in-service platforms.

• Establishing the Conditions for Future Capabilities. This element addresses the migration of the Aegis Integrated Combat System. Getting the AN/SPY-1 radar out of its tightly coupled radar control computer program with its customized computing plant and into an open architecture condition will allow for immediate improvements to support near-term warfare capability demands. In addition, the Aegis Weapons Control System must be uncoupled from its “niche” processing environment, and must be reusable in any platform expected to shoot Standard missiles. To achieve these objectives, the Aegis 3 spiral migration plan was developed, for execution under the cruiser modernization program.

Modernization Model for the Future

The Open Architecture Transformation Road Map was crafted to provide the specific conditions for the addition of future software-based capabilities. As such, it did not provide for significant warfighting improvements. Once in open architecture, however, a sustainable process for continuing capability insertion is essential. Equally important, the process must provide for technology hardware updates and software design improvements. The Rapid Capability Insertion Process/Advanced Processor Build will meet these needs.

It is driven by five influences:

• Pace of Technology. Increasing computer processor speeds drive both affordability and sustainability of computing hardware, as well as affect peripherals, cable layer technology, and software design. Manufacturers, on average, maintain supportability of their major products for about three years. The Navy has extended this obsolescence trend an additional year by organizing repair part lifetime buys.

• Naval Capabilities Process/Mission Capabilities Package. This generates an understanding of warfighting requirements based on future battlespace driven capabilities assessments. It provides decision opportunities annually, aligned to the federal budget submission.

• Federal Planning, Programming, Budgeting, and Execution (PPBE). The policy guidelines shaping PPBE require the budget to be shaped in two-year blocks, with an attendant follow-on four-year target investment, called the Future Years Defense Plan. The net effect of PPBE is that major shifts of investment can occur only on a two-year cycle.

• Systems Engineering Effort. The integrated backbones of combatants and aircraft are challenging environments, not only because of the complexity and magnitude of their software relationships, but also because of the quality-of-service demands of high-end weapon systems, time critical actions in the supported battle space, and challenging data structures. It takes 24 months for new software-based capabilities to be properly engineered, tested, and fielded.

• Small Business Innovation Research (SBIR). The submarine community harnessed the power of SBIR contracts to get acoustic capabilities migrated to modern software/hardware conditions. This effort, called the Acoustic Rapid Capabilities Improvement program, provided an early model relevant to the challenges of RCIP/APB.

Given these drivers, RCIP/APB was established with these characteristics.

• Hardware upgrades and improvements will be on a four-year cycle. The actual upgrade of computing on a ship will depend on when she was last subjected to a hardware upgrade, adjusted to her next major industrial availability.

• Software improvements will be targeted for a two-year cycle. Software-based warfighting improvements will be made based on prioritized capability needs identified by the mission capabilities package or fleet input.

Application of the RCIP/APB across the many “platform nodes” of the network-centric environment is no small task. Each node contributes capabilities required for the success of the joint force in the net-centric battlefield, as well as unique contributions specifically attributed to its character.

The Department of Defense has no choice but to move its combat systems to open architecture. The world has entered an era of rapid, technological globalization, marked by the threat of asymmetric warfare. Now is the time to embrace the power of open architecture and move aggressively to align Navy and DoD investment, acquisition policy, and budget execution to support it.

Captain Rushton has served aboard seven ships and was commanding officer of the USS Yorktown (CG-48) and USS Antietam (CG-54). He previously served as chief of C4 Plans, Policy, and Programs at U.S. Atlantic Command/U.S. Joint Forces Command, and currently is head of the Surface Ship Network Systems and Integration Branch.