Computerized command and control systems, such as the Army Battle Command System, gives commanders with the 4th Infantry Division and other units a virtual look at battlefields, complete with maps, terrain analysis and depiction of “friendlies” in blue and “hostiles” in red. The ABCS technology has already had an impact: Friendly fire killed three dozen U.S. soldiers in the first Persian Gulf War, while only a fraction died that way during the initial combat phase of OIF.

But ABCS still faces challenges. The underlying integration capabilities needed to effectively blend information from 11 separate systems into a cohesive battlefield view is a battle in and of itself. Years ago, the Defense Department developed the component systems, which manage everything from air firepower to logistical support and enemy movements, without any thought to being stitched into what DOD commanders today call a system of systems.

Integration efforts came to a head in 2003, when the Army mandated that its Program Ex­ecutive Office Command, Control, and Communications Tactical (PEO C3T) unit, headquartered at Fort Monmouth, N.J., marry the separate components together into a “good enough” version of ABCS, known as 6.4 and without some planned features, then roll it out across the Army. The bad news: PEO C3T had less than a year to complete the job. “We accomplished the task, but it did take some late nights and lots of coffee for software coders,” acknowledges Col. Harold Greene, project manager for Battle Command and the leader of the integration effort.

Now, as ABCS enters the post-good-enough era, the Army plans even more fundamental changes to tighten integration among the separate modules and to provide connections to the larger Joint Command and Control (JC2) initiative, which strives to improve collaboration among all the military branches.

The Army has learned digitalization lessons with ABCS 6.4, but complexities remain that show sophisticated systems engineering isn’t always destined for success.

This became apparent in January when the Army canceled a $900 million and rising contract with Lockheed Martin Corp. for the Aerial Common Sensor spy plane. Although not directly related to ABCS, the plane was a similarly complex technology and integration initiative, albeit one that never left the ground.

“Although the goals of better command and control are pretty easy to understand, we have entered into a realm of technological complexity that is so different, it is so unprecedented that I’m not sure existing contractors really have the capacity to achieve some of the transformation that is envisioned,” says Loren Thompson, chief operating officer of the Lexington Institute, an Arlington, Va., think tank.

For its part, the Army believes it has a not-so-secret weapon for helping make sure ABCS overcomes technical complexity: Maturing Web services technology that will underpin future versions of the ABCS and align it with the emerging JC2.

The Army isn’t the only military branch grappling with C2 digitalization. Through its Battle Management Command and Control system project, the Air Force is building a system that integrates data from intelligence and surveillance systems into a central interface for pilots. But tying together systems that weren’t designed from the start to share files has proved to be a schedule-busting effort for BMC2 (see story, this page).

ABCS 6.4 achieved quick-hit interoperability with a central server that uses a modest implementation of Web services technology. Web services are small nuggets of computer code that perform a specific task and that may be mixed and matched as new automation demands arise. Web services, and their use in the larger framework of service-oriented architectures, promise greater flexibility and adaptability for private- and public-sector IT organizations.

The central server in ABCS 6.4 uses a publish and subscribe service. Rather than forcing commanders to log into 11 separate C2 modules for needed information, the central server acts as a clearinghouse where the users, or subscribers, can download the so-called published data. Because developers of the 11 modules didn’t originally build in interoperability among the programs, “we had to go back and find the best way to get them to interoperate in a short time frame,” says Robert Mendoza, a program manager with MTS Technologies, an Arlington, Va., ABCS contractor. “The best solution that we came across was the common server.”

Next Stop: The Future
Now the server is pointing the way to ABCS’ future evolution. “We hope to get rid of the individual functional systems as they exist today and merge them together into core services on the network,” Greene says.

Already, Army product managers are implementing Web services for their individual ABCS modules. For example, the Battle Command and Sustainment Support System (BCS3) uses Web services for communicating internal and external data. In the future, Web services will be used for all information exchanges within BCS3 and battle command operations, says Lt. Col. Joseph Grebe, BCS3 product manager. “There are many benefits to Web services,” he adds. “[They] will allow data elements to be tagged so that these systems will be better able to handle, categorize, and filter data, and to make better use of available resources, such as transmission and storage media.”

The move to Web services isn’t only about long-range goals; the

John Emerson

technology could also have direct, near-term payoffs for the ABCS. “We are looking to standardize to the extent possible, and that has benefits in [IT] support and in training,” Greene says.

The Army’s first step in that effort is to rearchitect the 11 ABCS systems so they require fewer individual servers to power them. “Today, if you to go to a Maneuver Operations Center you would see a tremendous number of servers set up to support one of the 11 functional systems,” Greene says. But fewer servers mean fewer resources to maintain or troubleshoot when problems occur, he adds. Less is more for IT reliability, too. Greene says that as the ABCS program consolidates servers it will increase failover capabilities so if one server crashes another will quickly pick up the slack.

But converting the legacy applications into an amalgamation of agile Web services won’t be an exercise in instant gratification. In some cases, the Army and its contractors will wrap C2 capabilities with Web service outerwear, which will give the appearance of a modern Web service to other larger applications. “This is a lower-cost approach that can be done quickly,” says Curt Nutbrown, Lockheed Martin’s program director for the Global Command and Control System–Army (GCCS-A) and the Maneuver Control System (MCS).

Other modules, because of their greater complexity or because their capabilities require updating, will need to be rewritten as a Web service, a costlier but sometimes necessary alternative. “It’s situation-specific. We are looking at doing some quick hits for some applications. While for applications that may be around long term, we will need to start over from the ground floor,” Nutbrown says.

As ABCS’ Web services work evolves, the program will share individual services it develops with the larger JC2 community. “They have asked for nominations of pilot services, and we intend to nominate quite a few that we are developing as part of our ABCS migration over the next few years,” Greene says.

Eventually, the Web services approach could change how troops use digital C2 systems in the field. “Troops should have a screen in front of them that provides the tailored information they need very quickly, without forcing them to go out and search stovepipe systems,” Nutbrown says. “So they will gain access to information in a more timely manner for their decision process, while at the same time they won’t have to worry about the space, weight, power administration and logistics issues surrounding the care and feeding of a large amount of hardware.”

With wider Web services use, BCS3 users will be able to connect to more joint command data, which is limited in the current version, adds Grebe.

The Army also hopes more agile Web services will improve knowledge management, the ability to organize and efficiently make available information captured within its C2 applications. From the early ABCS implementations, “one of the lessons we learned was there’s a shortfall in dealing with significant activity reports and how we track them for SASO”—security and stability operations, Greene says.

Stumbling Blocks
Moving to Web services may be a worthy goal, but the transition will take time, not necessarily because the technology isn’t fully mature, but because of a number of other knotty technical and cultural issues within the Army and the rest of the military.

For example, the Army must also grapple with network bandwidth issues. “Today, we are somewhat constrained because we don’t have ubiquitous bandwidth at every echelon in the Army, and that is particularly acute in the Army because of how we operate,” Greene points out. Army units deployed in war zones are often spread out from one another, without the luxury of reliable broadband communications pipes—either wired or wireless—connecting them. As a result, the service plans to first run the Web services on local servers over LANs, and then open the services up to wide-scale sharing.

Web services will also require some new ways of thinking about technology, Greene acknowledges. “We grew 11 systems individually, and everybody was doing a great job—in the context of their system. What we are trying to do now is open up people’s vision so they don’t worry just about the system they work on directly, but also worry about the next higher system of systems,” Greene says. “We have to bring the system engineering up a level or two so we are making those decisions at a system-of-systems level rather than at an individual product level.”

The Army also faces the issue of having to upgrade ABCS in the midst of the Operation Iraqi Freedom firefight, when a software glitch can result in potentially life-threatening consequences. “We have to be very careful in terms of when we update these things because people are using them right now,” says Edward Shanahan, business development manager for Lockheed Martin. “We have to ensure as we are moving forward, that we don’t trip up the guys who are using the stuff right now.”

And while the Army is monitoring the ongoing development of independent Web services standards from industry organizations such as the Organization for the Advancement of Structured Information Standards and the World Wide Web Consortium, civilian organizations don’t always address specific military needs. “To the maximum extent possible, we would like to leverage [third-party] standards,” Greene says. “But I don’t think there is a commercial standard for calling in artillery or air support.”

purchase reprint

link to this page