Special Report: DCGS Integration Backbone forges joint ISR ground
The DCGS Integration Backbone forges common ground for service ISR platforms
- By David Perera
- Nov 17, 2008
The U.S. military has always sought to create advantages through situational awareness. But experiences in recent wars have placed a greater emphasis on receiving and integrating that information quickly.
Advances since the early 1990s haven’t been enough, said Air Force Lt. Gen. Michael Peterson, Air Force chief information officer and chief of warfighting integration, in an April Joint Forces Quarterly article. During the Persian Gulf War, the U.S. military failed to destroy any Iraqi Scud missiles before they were launched, despite monitoring missilepreparation activities. The Air Force simply “could not move information from sensor to shooter,” he wrote.
By 2003, the military reacted within an hour to intelligence that Saddam Hussein had entered a suburban Baghdad restaurant.
But by the time a bomber hit the building, Hussein had left. “Even though we compressed the decision cycle time from countless hours in 1991 to 35 minutes in 2003, it was not enough to operate inside the enemy’s execution cycle,” Peterson added.
The proliferation of sensors complicates the operating environment. Only two years ago, the Predator medium-altitude unmanned air system provided 12 combat air patrols. “Today we have 27 combat patrols of Predators and Reapers flying, and we’re building toward 50,” said Air Force Gen.
John Corley, air component commander at Joint Forces Command, during a June conference sponsored by AFCEA International.
In the past, the military handled intelligence, surveillance and reconnaissance data by dedicating specialized software and hardware to each sensor. That method inhibited information sharing and slowed the integration of multi-intelligence data.
With those problems becoming more pressing, the Defense Department decided in 2003 that the military services needed to refine their ISR distribution and sharing ability. The department needed a system that could move multiple data streams via a network that would allow users to quickly access and search the data. And that system had to be accessible across the services.
THINK JOINTLY, ACT LOCALLY
The result was a Defense Acquisition Board Oct. 24, 2003, memo that instructs the military services to adopt an Air Forcedeveloped ISR technology called the Distributed Common Ground System (DCGS) Integration Backbone. With DCGS, ground workstations create a system for distributing intelligence information.
The DCGS Integration Backbone (DIB), was originally designed as part of the Air Force DCGS, but “the Army and the Navy saw that and really asked for it to be more separated out, and that’s when the DOD folks got involved” to make it mandatory across the ISR community, said Air Force Maj. Guy Mathewson, director of the DIB Management Office.
The result is an approach to ISR distribution that spans all the services, which implement the system separately. Each service has a DCGS system, and the foundation of each is a DIB. The intelligence community and Special Forces Command also have a DCGS.
“We get asked that question a lot, ‘Why [isn’t there] a joint program office?’ ” said Marine Corps Lt. Col. Scott Camden, DCGS-MC project officer.
The DCGS systems vary because the military services have different battlefield needs, including how they use ISR information.
The Air Force uses DCGS as a high-resolution imagery distribution network and plans to add signals intelligence within the next few years. The service shares the high-resolution images mainly via five bandwidth-rich core sites. Each site’s processing requirements exceed 500 megabits/sec, said Air Force Lt. Col. Brian Ruhm, DCGS-AF deputy program manager.
“We use more of a reach-back approach,” he said. “It allows us to concentrate our intelligence analysts at the five distinct locations.” However, the other services want their DCGS workstations distributed throughout the battlefield, where bandwidth can be limited or inconsistent. DIB lets users tap into databases anywhere in the world – a laudable idea that needs modification to be effective in locations where bandwidth is low and connectivity is intermittent.
“If we had a battalion that had a store of ISR data operating on the tactical edge, we couldn’t have the data exposure point happen right from that battalion,” Camden said.
“You couldn’t have DOD-wide users doing some type of query and hitting directly back to that battalion’s set of hardware.” Also, not every military service needs the same set of intelligence, such as human intelligence or geospatial intelligence, in equal measure.
“We all face similar problems, we just feel them at a hotter temperature,” said Bob Poor, assistant program manager of the Navy DCGS Increment 1. “The tools and the focus and priorities are a little different in the other services. The Army has a much more deeply embedded tactical thought process. The Navy is at a much more operational level,” Poor added.
In short, because the military services have different DCGS needs, a one-size-fitsall solution was not an option. A joint program approach “would probably end up being a lot more costly and with it being a lot more drawn out,” Camden said.
The development of the military services’ DCGS implementations varies considerably, another reason for not creating a joint program office, said Gabe Leva, senior acquisition analyst who oversees the DCGS family at the Office of the Assistant Secretary of Defense for Networks and Information Integration. The office is responsible for all DCGS procurement.
“One joint program office would have caused the program that’s more advanced to slow down and, in some cases, back up,” he said.
The Air Force and Army have the two most mature DCGS programs. The Air Force’s latest version, 10.2, was first fielded in April and will be installed at all sites by the end of 2010, Ruhm said.
The Army took an existing capability called the Joint Intelligence Operations Centers ( JIOC) system and wrote resource adapters to make data feeds DIBcompatible, said Lt. Col. Daniel Cunningham, manager of intelligence fusion at the Army’s Program Executive Office for Intelligence, Electronic Warfare and Sensors at Fort Monmouth, N.J. JIOC had a centralized architecture, but the Army DCGS reaches the level of some battalions, Cunningham said. The Army’s next version should be available by summer 2009, he added.
The Navy plans to release a full DCGS implementation by spring 2009, and the service was scheduled to complete an initial deployment aboard aircraft carrier USS Harry S. Truman in October. The Marine Corps’ program is still in the technology development phase.
DOD formed a governance structure to oversee the services’ DCGS work. A two-star level ISR council monitors functional requirements, although the DCGS Board, led by a representative from the undersecretary for intelligence, does the bulk of the functional work.
The DIB, the foundation of the DCGS family, is a software stack that resembles service- oriented architecture.
“Some people would say it’s not really SOA, but really, it’s as SOA as SOA could be” when it was designed, said Mark Brigham, business development director of Raytheon’s Tactical Intelligent Systems division. Raytheon is the prime Air Force DCGS contractor and prime vendor on the next version of the DIB, which is set for final release in December. The Army also contracted the company to assist with its JIOC resource adapters.
The new DIB version, named the 1.3 release, will move the stack somewhat away from proprietary platforms that include Oracle and BAE WebLogic. “We want to be platform independent as well, and that’s the right thing to do,” Brigham added. Version 1.3 includes BAE WebLogic alternative JBoss Version 4.2.
The DIB’s main interoperability component is a metadata catalog that stores standardized metadata tags attached to ISR data. The DIB automatically tags the data, Mathewson said. “The actual ISR data is stored in a separate database, wherever that particular system is,” he added. The DIB metadata catalog stores only the tags.
Users perform searches and get returns from the metadata catalog. From there, they can access the data.
In the current version, systems administrators need to manually configure the IP addresses of the DIB nodes they want to access, Mathewson said. When the DIB was envisioned as a technology to connect just a handful of Air Force megasites, that was not a significant problem.
But a change was needed because the Army intended to distribute DCGS servers to battalions. Cunningham said 318 DIB Army metadata servers are in the field, including 62 in Iraq.
As a result, Version 1.3 will have dynamic node registration, allowing the system to automatically discover other nodes.
“There’s going to be some concept of operations issues on how that works that are yet to be determined,” Mathewson added, referring to the problems of battlefield locations with limited bandwidth. But as a result of a new synchronous query capability, searches won’t slow down if a particular node is unavailable, Mathewson said.
Version 1.3 also will incorporate some infrastructure services, such as access and authorization and federated search from the Defense Information Systems Agency’s Net-Centric Enterprise Services program, said Lorraine Wilson, deputy director of enterprise programs at the Office of the Undersecretary of Defense for Intelligence and chairwoman of the DCGS board. Search has always been a DCGS capability, but the NCES-supplied search engine will allow users to search beyond DCGS’s boundaries, she said.
However, for the foreseeable future, the DIB will need to be a type of defined software stack, Wilson said. Some military services with less mature DCGS implementations balk at the cost of incorporating commercial products specified by the Raytheon-developed DIB.
“Everyone wants to move to a more standards-based solution,” the Marine Corps’ Camden said. Commercial datasharing enterprises don’t rely on a specific software stack, just data standards, he added, citing travel booking Web sites as an example.
A pure data standards approach won’t work for DCGS, Wilson said. “When you get into how you implement some of these commercial off-the-shelf tools, it really drives the difference between ‘I can see your data,’ or ‘I can’t,’” she said, adding “I’ve witnessed it personally.” Wilson added that another reason for this concern is that DCGS seeks to facilitate networked ISR exploitation application services that accompany the DIB infrastructure in addition to being an information distribution network.
Like information sharing, sharing services will require concept-of-operations refinement.
“If you’re sitting back in downtown Washington, D.C., and I’m in Afghanistan, what’s the possibility of your service providing me the results that I’m looking for in a timely manner to support my mission?” asked David Usechak, an Army DCGS senior principal engineer.
Sharing computing resources across organizations brings up questions about accountability for availability and costs, and DOD has not resolved those issues. For the moment, however, those are problems that don’t require immediate resolution.
“As of right now, there’s very few services out there” registered into DCGS, Mathewson said.
That’s not to say that DCGS isn’t influencing warfighting. There’s a culture associated with DCGS at the Air Force, Ruhm said. “You have airmen and junior grade company officers and they’re working through chartrooms, they’re on voice connections with frontline fighters and units, they’re on a continuous link with the actual pilot with the sensors, and to watch them interact with their customers and to watch the level of support they provide, it’s something,” he said.