About Us Our Work Employment News & Events
MITRE Remote Access for MITRE Staff and Partners Site Map
edge top

Summer 2002
Volume 6
Number 2

 

Home > News & Events > MITRE Publications > The Edge >

Distributed Computing Aids Battlefield Control by Ed Shrum

We constantly hear about distributed computing technologies at conferences and read about them in trade newspapers and in new titles on local bookstore shelves. Many of the systems we take for granted in our daily lives such as cellular telephones, automated teller machines, and stock trading systems rely on distributed computing. Who in the military uses it? Which techniques does the military use?

Not surprisingly, the Army relies heavily on distributed computing technologies. Why? Ground operations need rapid recovery and redeployment from attacks, quick reconfiguration for new missions, easy scalability from platoon- to division-level activities, and immunity from single points of failure. These requirements imply smaller, lightweight hardware instead of large servers, and software functionality that is distributed across multiple machines.

Press coverage of military systems generally focuses on how warfighters use these systems, so we seldom hear much about the software technologies that underlie them. This article gives an overview of how the Army is using distributed computing and provides lessons learned from one specific project, including advantages and limitations encountered. It also highlights MITRE’s role in the transition to newer distributed technologies.

Battlefield Representation

The Army's Maneuver Control System (MCS) and the larger “system of systems” known as the Army Battle Command System (ABCS) have been using distributed computing since the early 1990s to connect with clients, internal processes, and external systems. Army commanders rely on ABCS to plan and execute battles, while MCS is the central system that interfaces with the other systems to gather tank and other units’ positions, field artillery information, intelligence data, air and missile defense inputs, combat support statistics, weather reports, and other data to display on a map background for the commander as the Common Tactical Picture (CTP).

Early versions of the MCS code simply used UNIX remote procedure calls, but the project soon migrated to the Open Software Foundation's Distributed Computing Environment (DCE). In time, problems developed as the move to an all-digital Army placed increasing demands on distributed systems.

DCE was efficient when passing small, simple data parameters, but as software became increasingly complex, it was too slow and unreliable for the complex data types required for today’s more sophisticated calculations. Memory leaks and other errors in the DCE libraries caused severe performance degradation when systems were heavily used over long periods of time. Random nonrecoverable failures meant that DCE had to be reinitialized every time the system was restarted, which caused system initialization times to become unacceptably long. The need to configure each computer as a single DCE “cell” blocked reconfiguration of the different functions resident on any given host and defeated some of the important Security and Naming service features. Because newer MCS software features an object-oriented design, calls to the more traditional DCE routines required special handling. As developers began to use the Java language to write their graphical user interfaces, special interface conversions became necessary, and this made DCE even more of a bottleneck.

In 2001, MCS redesigned its CTP module to improve performance. This redesign was particularly important because the CTP is reused by the other ABCS systems. MITRE played a key role in incorporating new technologies into the upgraded CTP. The Common Object Request Broker Architecture (CORBA) was used to replace the no-longer-supported DCE, and Java was used to speed up design of simpler, easy-to-use graphical user screens. MITRE headed a team that selected a CORBA vendor; and several MITRE employees who had expertise in distributed computing, CORBA, and Java were then assigned to work with the developers to design the new architecture, supply jump-start technical advice, and debug design problems. MITRE wrote development guidelines, evaluated security risks, and even provided a DCE-CORBA bridge to ensure interoperability with legacy systems.

MITRE’s design ideas enabled the screen developers to use Java’s Remote Method Invocation as a direct interface to CORBA without any conversions, and will also allow future development to interface directly to Sun’s Jini technology for mobile code architectures and to Java 2 Enterprise Edition (J2EE(tm)) application servers. Java screen prototypes in a MITRE services-based simulation of MCS had paved the way for these technologies, which made it straightforward to convince the sponsor of the need to incorporate these approaches. Detailed performance measurements of the final product showed that replacing DCE with CORBA yielded a tenfold performance improvement. This speedup was due to faster manipulation of complex data types and characterization of every battlefield object as a true object-oriented abstraction, allowing all objects to be cached for rapid retrieval and displayed on the map. Many user screens have been simplified and recoded in Java. The Army has successfully deployed MCS in several field exercises, and other systems within ABCS are now making similar transitions to CORBA.

Another example of just how far the distributed computing technologies are taking current military applications is the Joint Tactical Radio System (widely known as software radios). In this system all of the communications functions except the radio frequency hardware are built within a CORBA software framework. Also, the operational flight software for unmanned aerial vehicles uses CORBA to communicate with distributed components and controls of the aircraft.

In addition to supporting the object-oriented interfacing techniques that CORBA now provides to MCS, MITRE recently prototyped methods for interoperability between legacy systems and small hardware devices such as personal data assistants. MITRE has also constructed an exploratory prototype of a mobile code architecture using Jini, in which software is downloaded to the user’s device only when it is needed.

Currently, MITRE is constructing two prototypes that provide ABCS and MCS functions to users via a Web Services architecture; one is based on a J2EE Application Server design, the other on Microsoft’s .NET technology. These prototypes will undergo in-depth performance studies to evaluate the different technologies and various underlying protocols, as well as the effects of network bandwidth, transmission delays, and errors.

Distributed computing has played a critical role in Army systems and will continue to do so. Recently emerging real-time standards, written with input and guidance from MITRE staff, create new opportunities to apply CORBA and Java, open up the use of distributed computing in time-critical control systems, and provide important benefits to a wide range of users (see Standards for Real-Time Distributed Object Computing by Dock Allen). As J2EE, .NET, and Jini evolve, MITRE will prototype their architectural benefits and measure their performance. MITRE staff will continue to be involved with the emerging distributed computing technologies and can provide timely technical advice and guidance not only to the Army, but also to sponsors such as the Air Force, Navy, Internal Revenue Service and other civilian government agencies.

What is Distributed Computing? Why is the US Army Interested?
  • A distributed system consists of multiple executables interacting with each other
    over a network
  • Why use distributed computing?
    • Geographically diverse locations
    • Replication of functionality in mission -critical applications
    • Several small machines ate cheaper than one large one.
    • As capacity is exceeded, more machines can be added.
The Challenges Facing Distributed Computing
  • Different hardware platforms
    • Workstations, personal computers, notebooks, personal data assistants
  • Different software operating systems
    • UNIX, Windows, Linux, Windows CE, etc.
    • Each has its own internal data representation.
  • Interprocess communication (IPC)
    • Each process must establish a communications channel with every
      process it talks to.
    • Data formats must be converted.
    • Need to support multiple protocols: Sockets, IPC/RPC, TCP/IP,VME, Others

TCP/IP: Transmission Control Protocol/Internet Protocol
VME: VersaModule Eurocard


For more information, please contact Ed Shrum using the employee directory.


Homeland Security Center Center for Enterprise Modernization Command, Control, Communications and Intelligence Center Center for Advanced Aviation System Development

 
 
 

Solutions That Make a Difference.®
Copyright © 1997-2013, The MITRE Corporation. All rights reserved.
MITRE is a registered trademark of The MITRE Corporation.
Material on this site may be copied and distributed with permission only.

IDG's Computerworld Names MITRE a "Best Place to Work in IT" for Eighth Straight Year The Boston Globe Ranks MITRE Number 6 Top Place to Work Fast Company Names MITRE One of the "World's 50 Most Innovative Companies"
 

Privacy Policy | Contact Us