Digitized Battlefield Elements Tested for Joint Environment

May 2000
By Robert K. Ackerman
E-mail About the Author

Ensuring interoperability on the battlefield may begin in the computer design process, but it is verified in the electronic obstacle course.

The drive to speed new military information system technologies to the field, coupled with an increased reliance on commercial off-the-shelf products, is posing new interoperability problems for communicators. Many of these systems must interoperate in an increasingly networked environment with legacy equipment or foreign counterparts in coalition operations.

Before these systems are rushed to the field, they may encounter a digital speed bump at the Joint Interoperability Test Command (JITC), Fort Huachuca, Arizona. The command verifies interoperability both for new systems prior to their fielding and for existing equipment undergoing hardware or software upgrades. It also keeps alert for stovepipe legacy systems that might not function in joint or coalition network-centric environments.

Its work can range from determining commercial and military satellite communications interoperability to earthbound applications such as e-commerce. It can involve theater air and ballistic missile defense, unmanned aerial vehicles, tactical datalinks and the national imagery transmission format standard (NITFS).

The JITC is the sole command, control, communications, computers and intelligence (C4I) interoperability certifier for the U.S. Defense Department as well as an operational test agency for many department elements. It performs developmental test and evaluation on many systems, including some on which it is not engaged in operational testing. The command defines its mission as providing compatibility, integration and interoperability information to warfighters and decision makers over the entire life cycle of a C4I system.

Now that the command is free from its dominant role of testing for year 2000 bug problems, it is working to seek out new communications and electronic systems and test them for interoperability. This could take the form of evaluations performed in concert with vendors during development or testing regimens imposed on an already-fielded system that has not been certified for interoperability.

In addition to being an operational test agency, the JITC is the only nonservice member of the major range and test facility base (MRTFB). As an MRTFB member, the command can permit a commercial vendor to rent its facilities to test for joint interoperability before selling a system to the military. “This is a real advantage—if they use it,” declares Col. Thomas L. Andrew, USAF. Col. Andrew, the JITC commander, adds that some commercial vendors do make use of this capacity. The vendor pays for the testing up front, and the item is already interoperable when it is deployed to the field.

The JITC is a field command of the Defense Information Systems Agency (DISA). Roughly three-quarters of the more than 500 people located at Fort Huachuca are contractors, though this number varies according to the specific testing underway. Less than 10 percent are military.

Although the facility at Fort Huachuca is the command’s primary location, a smaller site is located at Indian Head, Maryland. This facility formerly focused on maritime matters, based on its U.S. Navy origins, but it and its personnel distribution are shifting into the joint realm. Recent assignments include a large amount of Defense Message System (DMS) testing. The Indian Head unit has about one-quarter the number of people as the Fort Huachuca JITC, but its proximity to the Pentagon and the high-technology companies along the Capital Beltway bode well for an increased role, JITC officials say.

“Interoperability is not a [single] problem, and there is not a [single] solution,” Col. Andrew warrants. While some people believe that at some point interoperability will be achieved and never will be a problem again, that is just not true, he emphasizes. “Interoperability is a challenge; it always is going to be here; we always are going to fight it; and we always will have to work to make things interoperate.

“I feel very comfortable that JITC will always have a job.”

In some cases, it may boil down to procedures. The colonel cites the example of two identical tactical telephone switches that do not interoperate in the field because different individuals set master timing independently on each switch. When the command tests for interoperability, it is looking at more than equipment. In addition to procedures, the JITC examines user training.

Nonetheless, heading off interoperability problems at the vendor level is a major priority.

“A vendor necessarily does not want to be interoperable,” Col. Andrew declares. “They would rather be noninteroperable. That’s just business. If I sold something, and I could hold the Defense Department hostage to buying my product, I would do it.” This approach often places the center at odds with business practices. “What makes commercial sense doesn’t necessarily make Defense Department sense,” he notes.

The colonel adds that a related problem is the belief that good standards can ensure interoperability. “Standards just cannot be written specifically enough to ensure that,” he says. “We have items that we do standards conformance testing on in the center. They meet the standard, yet they will not interoperate.” One cause might be that interpretation of a standard might be too broad, for example.

In one recent case, a vendor brought an imagery viewing product for testing. The JITC tested it to the NITFS, which it met. When the command tested the product for interoperability, however, it discovered a potentially serious problem. When a user marked a target graphically and stored the annotated file in an archive, another user employing a different viewer called up the file only to find that employing the new viewer caused the targeting mark to shift to another object. This could have had serious ramifications in mission planning, especially for air tasking orders where an incorrect target mark could have international repercussions. The command’s solution was to develop and implement an imagery standards validation and conformance test program.

The military’s increasing use of commercial communications equipment generates another problem. Commercial equipment manufacturers understand how to build equipment that works in the commercial arena, but they often do not understand how to incorporate unique military features through a telephone network.

Software is another key focal point for JITC testing. Col. Andrew allows that any time a software load is modified, it should be submitted for interoperability certification. Most major software releases for existing systems pass through the command. A recurring problem is that many commercial off-the-shelf software programs are tweaked for military usage, which can also introduce unintended changes. “You have to be careful how you define ‘commercial off-the-shelf’ and ‘shrink-wrapped,’” the colonel cautions. “Within the Beltway, there are a lot of folks that think commercial off-the-shelf is the answer.” Some commercial computer hardware and software products are incompatible, so this approach does not necessarily solve interoperability challenges, he notes.

Central to the command’s testing activity is ensuring that new systems and legacy equipment can interoperate. Because the military does not do “100 percent changeouts,” new gear must interoperate with older materiel, the colonel notes.

Many systems that have been fielded or are currently being fielded have not been certified for interoperability. The center has initiated several measures to ensure that these systems work better, Col. Andrew relates. These measures include writing letters to program managers for uncertified systems and briefing the military communications and electronics board biennially on systems’ interoperability status.

In particular, the intelligence community is “very stovepiped and uninteroperable,” the colonel states. This translates to duplicate field systems and some related gear that cannot communicate. In many cases, vital intelligence acquired by one system cannot be transferred to another.

The command has a major initiative underway to establish inroads into the intelligence community. It involves a proposal to have the operational test community help pay for some investments in a large offline network to test intelligence systems. This would permit the JITC to view these systems as a whole entity rather than as stovepipes.

The command tries to avoid “stand-alone” interoperability testing, Col. Andrew allows. The aim is to perform the interoperability assessment during developmental or operational testing. A stand-alone test, depending on the degree of complexity in the tested system, could run from hours to weeks.

In its testing efforts, the JITC uses substantial modeling and simulation as well as stimulation. The command includes loaders that can replicate thousands of telephone calls or messages, for example. These types of systems represent “the biggest payoff” among new technologies used in the command, the colonel allows. The proliferation of router connectivity allows the JITC to perform a significant amount of testing without actually being at the tested system’s site, which allows more long-distance evaluation.

Funding already is in the pipeline to build an offline global information grid (GIG) or defense information systems network (DISN) testing capability. The colonel explains that the cost of finishing this GIG testing will be less than building an equivalent test suite from scratch. Acquisitions will include newer asynchronous transfer mode switches and adding a teleport capability to the command’s in-house standardized tactical entry point (STEP) site.

Because most military leaders have accepted the likelihood of joint operations, the services are engaging in more joint exercises and training. This also demonstrates the real drawbacks of stovepipe systems, the colonel allows.

Nonetheless, cultural resistance remains in the services. “‘Not invented here’ is alive and well,” Col. Andrew says. Each service supports interoperability, but in many cases it wants jointness to be built around its own service-specific system.

The services cooperate fairly well with the JITC, he adds. The command also works closely with service operational test agencies.

The JITC participates in many military exercises, and one reason is to identify equipment in the field that has not been certified for interoperability. When this type of equipment is discovered, command personnel identify and contact the program manager to submit the item for testing. Col. Andrew warrants that if the program manager does not respond to this request, then the command contacts the program executive at the flag level.

Many commanders in chief (CINCs) provide the JITC with a wish list for each coming year. The command in return establishes priorities and determines needed funding, some of which may come from the CINCs. During real-world operations such as Bosnia and Herzegovina and Kosovo, the JITC provides personnel in theater for testing. The command has a shelterized capability that can provide near-real- and real-time analysis of some networks.

Recent interoperability evaluations have included the global command and control system (GCCS) and the DMS, both of which are extensive systems going through iterations. The command is performing modified developmental testing on the GCCS in which it brings in users during development and integration testing for an operational look at the application before it is put into the system. The Joint Electronic Commerce Program Office (SIGNAL, March 1999, page 17) has visited the command for an engineering conference on e-commerce issues.

Currently, a major JITC activity is the Department of Defense interoperability communications exercise, or DICE. This is predicated on the Communications-Electronics Command’s (CECOM’s) annual global software release. The JITC assembles a myriad of tactical switches, both local and long distance, against which it tests the software. CECOM performs the test for joint interoperability certification, after which it releases the software to the field. Col. Andrew adds that last year’s DICE generated 16 certifications.

Every year, the JITC solicits the services for unit participation. This year, for example, U.S. Marine Corps units provided unique MSE-63 message switching. Davis-Monthan Air Force Base, Arizona, recently upgraded to a new Air Force C4I system that includes a commercial private branch exchange (PBX) and a data module based on Cisco routers. The 35th Signal Brigade at Fort Bragg, North Carolina, supplied a forced entry switch, and Travis Air Force Base, California, provided a lightweight multiband satellite terminal. U.S. Navy facilities, including ships, contributed switch multiplex unit (SMU) capabilities.

The DICE architecture, with its mass of systems interlocked in a near-nightmarish network, does not represent a simple task for determining interoperability, JITC officials say. Connecting end items is complicated enough, but modems and cryptographic gear also must be factored into the interoperability mix. The network hinges on the software test, and the command builds the other interoperability tests around it.

The command has had its problems “getting its hands around” the DMS, officials note. The services keep changing elements, with some planning to resort to automatic digital network, or AUTODIN, support. Currently, units deployed with a message system terminal will transmit back to a STEP site. Three active AUTODIN switching centers provide the bridge between AUTODIN and the DMS.

Another problem emerged with secure telephone equipment (STE). Testing with CECOM and the National Security Agency revealed an inability to talk from a four-wire deployed STE to a two-wire STE. The difficulty focuses on which end “punches the button” to initiate secure links. Removing and replacing a Fortezza card could neutralize it, for example.

An additional STE drawback is that this type of link requires an integral gateway function that permits synchronizing a tactical STE with the two-wire strategic side. This setup comprises a dual modem, permitting each side to synchronize halfway. Unfortunately, these units are no longer manufactured, and no one remembered to request them in the fielding plan. The only service submitting requirements for STEs was the Navy, and it did not need the gateway function devices with its shipboard PBXs. Neither the U.S. Army nor the U.S. Air Force submitted any requirement for STEs.

Other systems experienced different types of software glitches. One type of software failed because the original startup disk provided by the contractor did not work. Replacement disks sent by the contractor solved the problem. In another case, the software required a new release, which allowed for an easy solution to the problem.

In the course of its testing, the JITC goes beyond merely giving thumbs up or thumbs down on system interoperability. If a system fails its testing, the command probes to determine the cause so that conflicts can be resolved. This information is fed back to the contractor or program manager.

The JITC aims at uncovering Priority I “show stoppers” that prevent a system from receiving certification, its officials say. Priority II, III and IV faults sometimes can be solved with a work-around, which the command aids in developing. Sometimes, a problem with one unit might not emerge with another deployment. The user can decide whether the work-around is acceptable for broad-based employment.

The command faces several major challenges in its testing regimen. The Defense Department’s fast track acquisition process requires the JITC to keep up with development. The differences between service and joint acquisitions also pose problems. Service program managers are more concerned with rapidly fielding a system than with implementing its joint characteristics, and the command must pick up the slack to ensure interoperability.

In a distributed operational environment, many managers do not realize that they ultimately could be connecting internal systems with those of other services. In network-centric warfare, a small system being fed data may be connected with other warfighters in other services.

Training in military communications and computing “has really gone downhill” in terms of the breadth of instruction, Col. Andrew contends. Most training in the field “is, at best, at the black box level” in that it focuses mostly on technology control rather than on electronics technician capabilities. He states that the JITC still has technicians and engineers who can delve into the details of a system and improvise or adapt technology to suit requirements.

Connecting commercial gear to a military cryptographic unit, for example, might require a cable with unusual connectors on each end. This knowledge is not always available to exercise participants in the field. “In some exercises, we’ve built some 200 cables,” he notes.

Enjoyed this article? SUBSCRIBE NOW to keep the content flowing.