Defense Daily :: Navy Developing Path Forward For Open Architecture Implementation

By Geoff Fein

While the Navy continues its internal debate on which direction to pursue for surface ships, the service has begun to lay down the ground work, schedules and goals for implementing open systems architecture in order to reduce the cost and speed up the time cycle for delivering capabilities to warfighters.

For several years the Navy has been discussing its plans on how to require open architecture in new contracts, which contracts would be best to begin with and when those efforts should start.

There are several aspects to open architecture: a technical aspect, a business aspect, and a cultural aspect that must be considered, Rear Adm. Terry Benedict, Program Executive Officer Integrated Warfare Systems (PEO IWS), told Defense Daily in a recent interview. “And you’ve got to go after all aspects or you will not be successful.”

Industry has at times been critical of the pace of the Navy’s open architecture (OA) efforts, but Navy officials have maintained all along that this new approach is not something that can be done overnight. If the Navy tomorrow said it was going to OA and all parts of every system would be open, there would be unacceptable risk for the investments that have been made, Benedict said.

IWS is the chair of the Open Architecture Executive Team (OAET) that includes all of the Navy’s PEOs; and Office of the Chief of Naval Operations (OPNAV) sponsors from the surface warfare (N86), submarine warfare (N87) and air warfare (N88) divisions.

The group had its first two meetings this year, Benedict said, and it is planning to meet about three to four times a year to discuss what each of the PEOs and organizations are doing to achieve the Navy’s Open Architecture requirements and how the organizations can take advantage of the individual Systems Command (SYSCOM) and PEO initiatives and apply them across the entire Navy Enterprise.

An early effort Benedict pointed to were contract guideline documents, pushed to all of the acquisition community, that contain “common clauses that can go in contracts that help shape the government rights, non-proprietary, OA philosophy that people are really starting to use,” were pushed to all of the acquisition community.

PEO IWS has also developed sets of questions to determine a program’s openness that have been incorporated into the Navy’s new acquisition Gate process.

“We have actually developed six different sets of questions for Gates one through six, that now [a program manager] can use as programs go through the Gate process to determine a program’s compliance with the OA philosophy,” Benedict said.

“All these actions are necessary, to ensure policy and governance compliance, but industry truly desires to understand where are we going from an execution standpoint. My job as the OA lead is to ensure compliance to policy as well as develop an execution plan with acceptable risk.”

When Benedict took over as PEO IWS after Rear Adm. Michael Frick was selected as Vice Commander Naval Sea Systems Command (NAVSEA), he met with then Navy acquisition chief Delores Etter for a series of discussions to examine where the Navy could begin to execute its OA plan.

There are five areas Benedict said he could adjust and focus execution: Aegis, the combat system for DDGs and CGs; Ship Self Defense System (SSDS), which is the combat system for large deck amphibious ships and aircraft carriers; the Littoral Combat Ship (LCS) with its two distinct combat systems; DDG-1000; and CG(X).

Because CG(X) is still in the analysis of alternative phase, and both LCS and DDG-1000 are in development with contractor-specified combat system designs, Benedict noted there are really only two major combat systems he can help shape for immediate OA effect–the Aegis modernization effort for DDG-51s and CGs, and SSDS for CVN-78 and CVN-79.

The initial goal of OA, he added, was to separate the software from dependency on specific hardware and migrate to commercial-off-the-shelf (COTS) computing environments. “The goal was to break the ties between hardware and software and then put the hardware and software on different refresh cycles. You want the software on the faster cycle but you want it to work on the latest available COTS hardware platforms,” Benedict explained. “And then, periodically, you upgrade the hardware to take advantage of the technology leaps in COTS processing.”

Newer combat systems were designed from the beginning to be modular and to run on COTS processors and networks. The challenge has been to modernize the AEGIS fleet, which has an older architecture based on militarized equipment. Back in late 2004, the goal was set to move toward breaking the latest AEGIS software baseline from its legacy hardware by 2008. That effort would be known as Advanced Capability Build (ACB) 08.

“We have met this goal. Our next goal is to start developing modular software applications, where you break apart the monolithic software into modules with well-defined interfaces which will ultimately allow you to start competing across platforms for a common software object or software function,” Benedict said. “Ultimately in 2012 and beyond you get to fleet-wide introductions of common combat system modules in Aegis, SSDS and DDG-1000.”

One common application effort began two years ago with the awarding of a competitively bid contract for a System Integrator Design Agent (SIDA) to General Dynamics [GD] Advanced Information systems (AIS). “It was to develop the open architecture track manger,” Benedict said.

“We had to break down some cultural barriers, and I give Lockheed Martin and GDAIS credit,” he said. Both contractors, Lockheed Martin [LMT] and GDAIS, stepped up and said they would work collaboratively on this effort. Their combined actions to date have been outstanding. Benedict added.

The problem today, he said, is that every combat system has a track manager–there is a track manager in Aegis, a track manger in SSDS, a track manager in DDG-1000–and they are all different. “We pay every time somebody touches a track manager.”

When work on the SIDA contract is done, there will be a single system track manager and track server for both Aegis and SSDS.

Those components will also be given to Raytheon [RTN] for use in SSDS.

“This is our goal, you take a company, it may or may not be one of the major primes, to develop a software object, and you hand those objects over to a platform integrator to integrate,” he said. “This has taken a lot of time and effort to work through the details, but this is what OA is about. ACB12 will prove you don’t have to have a monolithic contract, where the primes are totally in charge of everything. We now start to open up and take advantage of other industry partners and small business innovation. I believe we are absolutely moving toward the Navy’s goal of Open Architecture.”

“We competed the common processors, that competition is in the Government selection process today. We competed and awarded a competitive contract for common displays. We now have one common display that we are using across the system, not just in surface [ships] but PEO IWS has been working with Chris Miller (PEO C4I) and to the extent that he needs that common processor or display in CANES [Consolidation of Afloat Networks and Enterprise Services], he is going to draw from that contract, Benedict said.

“We are starting to actually affect contract vehicles as well as the software objects and hardware procurements. We are more coordinated, not just across programs, but across SYSCOMs and PEOs,” he added.