Flexible Software Drives Marines' Experimental Battle Laboratory

Off-the-shelf programs and hardware lend versatility and cost effectiveness to proof-of-concept forward air defense system.

The U.S. Marine Corps Command and Control Battle Laboratory experiment is using modular, easily configured software to achieve visualization and coordination of battlefield radar and communications data. This project provides a picture of ongoing efforts throughout the armed forces to create sophisticated battle management technologies. Designed as a testbed for future air defense and command and control systems, the battle laboratory combines forward-looking new concepts while providing an off-the-shelf hardware and software environment.

An offshoot of the Marine Corps and U.S. Navy’s command and control and cooperative engagement capability (CEC) efforts, the battle laboratory in Quantico, Virginia, was created to study cooperative engagement techniques by connecting into the existing CEC network and advancing its capabilities.  The laboratory’s primary orientation is air defense, which ties in with current Marine Corps concepts such as fighting in littoral zones, Capt. Don Gordon, USMC, the battle laboratory’s project officer, notes.

The goal was to adapt the Navy’s core CEC efforts to a more mobile, lightweight, low-cost, in-tent environment that could be moved and set up in a matter of hours as opposed to weeks of installation time on a ship. According to John Blincoe, an advanced concepts/prototyping engineer with the Cooperative Engagement Program Office, the Marine Corps needed an integrated air picture that included identification and command and control capabilities while providing a high-level, accurate and continuous picture of the battlefield. The laboratory uses tactical datalinks, identification friend or foe sensor data and other information transmitted through standard tactical radios.

For air defense, the laboratory has provided proof-of-concept targeting and interception data for the Marines’ Avenger anti-aircraft system and the advanced medium range air-to-air missile (AMRAAM)-based complementary low-altitude engagement system known as “CLAWS.” Blincoe notes that the battle laboratory has been tested through a series of live missile shoots at Eglin Air Force Base, Florida, over the past few years. In its current configuration, the laboratory can detect targets through connected radar systems and automatically send that data downrange through tactical links providing direct cueing and support for the missiles, he says.

Two pieces of software are at the heart of the battle laboratory. Developed by Solipsys, a Laurel, Maryland-based software engineering firm, they are the tactical display framework and the multisource correlator tracker. Written in Java, the display framework handles the laboratory’s display systems and graphic interfaces. The correlator tracker is written in American National Standards Institute (ANSI) C++ and is used for handling and synthesizing data. Hardware muscle comes from one or more Sun Microsystems servers running the correlator tracker, while up to a dozen laptops operate with the tactical display framework.

Because it is written entirely in Java, the tactical display framework is completely platform independent, Blincoe says. It has been loaded without modification onto a variety of laptops, desktops and even SPARC stations, he adds. The software is highly modular, and because of its extreme compatibility, it can operate within standard World Wide Web browsers such as Netscape Navigator or Microsoft Internet Explorer, and it is year 2000 compliant.

The tactical display framework utilizes Java to generate the user interfaces and items such as pull-down menus, specialty panels and dialog boxes. It also provides operators with situation awareness displays, tactical decision aids and target engagement capabilities.

Plug-in technology plays an important part in the tactical display framework because new applications are commonly written in this format, Craig Vandervest, director of information synthesis systems at Solipsys, says. If a customer wants a new capability, it gets written in Java to create the plug-in, he adds. The dynamically configurable software is capable of providing two- and three-dimensional views of geographic and vehicular data. It is also entirely off the shelf and uses nonproprietary technology. The company claims this ensures seamless integration with commercial applications such as word processors, presentation and analysis packages.

The other half of the battle laboratory’s software package, the multisource correlator tracker, does the computational heavy lifting. This program is a collection of reusable software components providing a generic information synthesis and data-fusion capability. It correlates high-fidelity, real-time local radar information with remote, real-time and over-the-horizon track sources. Using a prioritized association list process, real-time radar tracks can often be associated with nonreal-time and over-the-horizon track information from national sensor systems and commercial air traffic feeds from the Federal Aviation Administration.

Vandervest notes the reason this piece of software is written in ANSI C++ instead of Java is because Java is more suited to interface-related applications. However, low-level data manipulation is not Java’s strength, he adds. ANSI C++ is better at this task, and it also has the advantage of being more efficient in execution speed. Because of this, any data processing applications fall into the correlator tracker’s end of the product spectrum and are done in ANSI C++, he notes.

The multisource correlator tracker also supports a number of message protocols including CEC, SABER, TADIL-A, TADIL-B, TADIL-J, OTH-Gold, TRAP/TRE, GBDL, JCPI, FAA and CD2. It has been interfaced with systems such as the cooperative engagement capability, the joint maritime command information system, the AN/TYQ-82, the advanced programming concepts air defense systems integrator, the Lockheed Martin multisource correlation system, and the tactical strike correlation module. Like the tactical display framework, the correlator tracker’s software is written with a modular, open design making any new interfaces or updates easily installable without affecting the existing programming. The software can also be configured as a stand-alone system or optionally networked into visualization products such as the tactical display framework. In the context of the battle laboratory, Solipsys created an interface message set that allows the Java-driven tactical display framework to communicate with the correlator tracker that is ANSI C++ coded.

As individual software packages, the tactical display framework and the multisource correlator tracker have applications beyond the battle laboratory, explains Vandervest. The laboratory’s current combination of the two creates one type of tactical package. The correlator tracker was used in the Marine Corps’ URBAN WARRIOR EXERCISE in San Francisco in March, (SIGNAL, June 1999, page 99), where it served as a testbed command and control system aboard the command ship USS Coronado. While the software was tested, its role in the exercise was completely separate from the way it is employed in the Marine Corps battle laboratory, he says.

This flexibility allows Solipsys to rapidly incorporate customer input and to make necessary software changes in a short period of time—days or weeks in some cases, says Blincoe. The Marine Corps is pleased with these qualities, Capt. Gordon adds.

Rapid response to requests such as operator-inspired customer changes are easily accommodated because of this flexible software environment. According to Vandervest, the firm learned to develop techniques to make the development process quick and easy. Part of this was accomplished by creating reusable data libraries of paradigms and objects. The components can be recycled, making it relatively easy to put together new additions to the software, he says.

One effect of being a proof-of-concept testing platform with a flexible structure is that each exercise is a new learning experience and a shakeout trial. Completely unexpected things are often learned through this process, Vandervest observes. Systems advertised as producing a certain type of data may or may not do so under field conditions, or they may produce unexpected results. Due to this constant learning curve, battle laboratory engineers adopted an expeditionary approach to speed up the learning cycle. As every demonstration is an experiment, the processes of innovation and the integration of new data are accelerated, he says.

This dynamic environment has taught Solipsys some lessons, claims Vandervest. Self-protection is important. This includes acquiring full documentation and meeting early on with other project groups and clients to understand a particular operational environment. As plans evolve, communications with clients increase exponentially the week prior to an event, an effect that can be anticipated, he says. Ambiguity is another issue in coordinating demonstrations. This is because many groups do not have an operational plan until a few weeks before an event, in which case quick preparation is necessary. Planning for contingencies is important. In case of unexpected events, the battle laboratory team takes more software and equipment components than it expects to use in a given demonstration. Solipsys also takes a full development environment every time the laboratory is deployed. Additional staff members are kept on standby in case they are needed. This kind of preparation comes from having done this multiple times, Vandervest points out.

Documentation has been the largest hurdle in developing software applications for the battle laboratory, Vandervest believes. This is because if they work with an existing system that has proprietary interfaces, the developers of those interfaces will not usually give them out for use. If they are owned, such as documents controlled by the government, for example, there may not be an acquisition problem. But even here, there can be difficulties between program offices, he says. Developers at a particular office could have created a system, but they might not want the laboratory using what they perceive to be their work product and will not provide the documentation. However, when it comes to getting the information needed to do the job, accommodations can be made. He notes that when working with firms like Lockheed Martin and Litton Data Systems, they essentially created joint ventures to work with their proprietary products.

In the future, Blincoe sees the battle laboratory concept moving beyond the Marine Corps and into the joint service world. He notes that the U.S. Air Force has been interested in the laboratory’s adaptable framework and how operator-inspired software changes can be made almost at field level.

Likewise, Capt. Gordon believes that the battle laboratory represents the direction in which the armed forces are moving concerning command and control. He notes that a result of the concept receiving so much attention is that other services will begin developing similar efforts. While Capt. Gordon is not sure where any of these developments can lead, he does know the battle laboratory fits a needed experimental concept as the Marine Corps and the Air Force are looking at replacing existing legacy command and control systems. He predicts that one outcome will be greater ties between the services as new cooperative engagement concepts are tested, and with that level of coordination, strong interoperability will be in place once an actual system is decided upon for development.