Printer Friendly

Poor man's digitization of the battlefield.

The 3d Infantry Division spends the majority of its time deploying and preparing for future missions, as opposed to testing software that digitizes the battlefield. Although the Army did not field the latest versions of the Army Tactical Command and Control Systems machines to the 3d ID, the commanding general and his staff emphasized the need to integrate all of their tactical systems regardless of their documented compliance levels for their Warfighter Exercise in 2002. Armed with command emphasis, the 3d ID G-6 began a quest to integrate the tactical systems and present a near real-time digital common operational picture of the battlefield. The 3d 1D G-6 integrated its command and control computer systems including the Tactical Website, an Army developed command and control website, without an extensive number of contractors and costly software upgrades.

Web-based command and control

The 3d ID's TACWEB remains the commanding general and chief of staff's information dissemination system of choice. In 1997, the original creation of the TACWEB began at 2d ID in Korea based on MG Walter Sharp's vision. At this time, he was BC Sharp, and the 2d ID's ADC(M). He tasked 2d ID's G-6 to design a web-based system that could roll-up the division's reports to provide an overall view of the division's status. In addition, the system had to be easily modifiable in order to meet the commanding general's continually varying requirements. The TACWEB follows the concepts defined in the Army White Paper: Concepts for the Objective Force. The white paper states specifically:

Web based C2 systems enable commanders to reduce decision cycles within their organizations by engaging subordinate leaders and staffs in collaborative planning and decision making at all levels within units. Web-based C2 systems facilitate the rapid dissemination of orders to the lowest levels, thus maximizing time available for tactical units to prepare for, to synchronize and to initiate decisive action.

3d ID's TACWEB, based on the original 2d ID's TACWEB, consists of a very developed website that contains all major reports for units and staff elements. The software required to run the website is Microsoft Structural Query Language Server, Cold Fusion and Microsoft Internet Information Server. As reports are filed, they can be accessed through the battle status page. The most current reports are displayed, and past reports are archived. MG Sharp's primary concern dealt with the logistics situational reports in TACWEB. It did not make any sense to enter the same data in two different systems, which is why he determined CSSCS and TACWEB should share the data.

The primary unit reports contained in TACWEB are the Sitrep, personnel data summary report, personnel requirements report, logistical Sitrep, communications status and various chemical reports. The units are required to report their status at specific time intervals. Once the units submit these reports, the data enters into the database immediately, and the roll-up reports automatically reflect the changes. This dynamic content gives all commanders instant access to updated combat status throughout the battle. In addition, it allows the division staff to spend more time projecting future requirements as opposed to crunching numbers and creating power-point slides.

The Sitrep provides the most important data to the commanders. The Sitrep contains unit location information, equipment status, current and future operations information, and overall unit status. The unit location section provides the units with the ability to enter a left, center and right military grid coordinate for the unit's subordinate unit positions. The initial integration effort began with taking these grid coordinates and plotting them on a digital map. The 3ID did not have a digital map plotting system, however it soon would acquire one to meet this need.

Initial integration

In April of 2001, 3d ID began evaluating a tactical system that hasn't quite been accepted as an ATCCS system in its own right, however 3d ID relied on it more during Warfighter than all other ATCCS systems combined: maneuver control system light. The major difference with MCS-L and its bigger ATCCS brothers remains the platform MCS-L runs on. All other ATCCS machines run on Sun workstations running Solaris, while MCS-L runs on any laptop with Windows 2000 and Office 2000. MCS-L can store data in different ways: as a standalone system, in a small-group shared environment, or with a central SQL database server on a database called the joint common database. The 3d ID used the latter for their Warfighter in 2002. The DAMO chose this option because it enabled the division to share data between TACWEB and MCS-L.

In July of 2001, code was added to the TACWEB that posted the unit locations from the Sitrep into the MCS-L JCDB as a graphic on an operational overlay. The most difficult part of this process turned out to be converting the grid coordinate from military to latitude and longitude. The JCDB's design allows many different systems to share data, and since the majority of other mapping systems use latitude and longitude, the JCDB does also. The formula for this conversion is not trivial. Fortunately, the MCS-L team provided our G-6 with a dynamic link library that contained the functions for many different coordinate conversions. After linking these functions into Cold Fusion, we could post unit icons onto MCS-L from TACWEB Sitreps. The G-6 demonstrated this feature to the CG and unit commanders and they accepted this as the 3d ID's primary "blue feed" to show friendly unit locations on a digital map. This integration began the building of our common operational picture on MCS-L.

Although this integration succeeded initially, the G-6 had a lot more work ahead for future integration. CSSCS integration ended once 3d ID upgraded to a version that allowed a Netscape browser to pull information off of the combat service sSupport control system. We integrated CSSCS into TACWEB by merely providing a link to one of the designated CSSCS boxes. The next systems that needed integration at this point were air missile defense workstation, advanced field artillery tactical data system and remote workstation.

Integration testing

In August of 2001, 1LT Robert Pitsko and I brought one of each ATCCS machines in the division to the battle simulation center for integration testing. After speaking with the contractors, we gathered enough information in order to make the systems communicate with each other using United States message text format messaging. The table below displays what each system uses to communicate, and which database they store their information.

After gathering data, we had to make the decision to try to use open database connectivity to the database or their standard messaging. In the past, we made an ODBC connection from Cold Fusion to the Oracle database on RWS. However, this kind of connection required a different knowledge base from the contractors of the ATCCS machines. In addition, we didn't think the other contractors would be comfortable with a direct connection to their database.

USMTF messaging remains quite unique because it uses double addressing. The message itself relies on a simple e-mail template with typical e-mail addressing (i.e. AFATDS used Within the e-mail body, there is an ATCCS alias (sometimes referred to as the OR name) consisting of a 32-character identifier for that machine. This addressing scheme adds complexity to the entire system. Defining the ATCCS alias can cause many problems because spaces at the end would commonly be truncated, which lead to undeliverable message failures. The e-mail address typically became the hardest part to set up when sending messages from the ATCCS box to the mail server (since we ignored the alias).

Initially we used Argosoft Mail server as the receiving machine for messages, and later used Microsoft Exchange Server 5.5. Since MCS-L clients only used JVMF, we decided to build a universal parser on the server in Cold Fusion that would accept messages from AFATDS, AMDWS and RWS. The end state for receiving messages was to accept operational graphics from AFATDS and AMDWS, and the enemy picture (Red Feed) from RWS. Although we wanted specific operational messages, we initially tried to receive a free text message from them first. This is where we ran into the problems that the rest of the ATCCS community faces: setting up the ATCCS address book.

Since we used such a light and configurable mail server, we quickly noticed the central problem: the e-mails from each machine were incorrectly addressed. Argosoft shows all connections, and logs all messages rejected, incoming or redirected. This log provided an invaluable source for information, in addition to our Ethernet sniffer we ran to view all transactions. After hours of frustration we digressed to the old Army standby and got out our butcher block. We wrote on a butcher-block board the Internet protocol addresses of each system, host names, user names and domain names for each system. With the previous confusion now neatly in order we began the initial part of the integration.

Anomalies develop

Although we initially defined our e-mail address as, we started receiving messages to mcs@mcs, mcs@d3mcs,, and mcs@[]. Argosoft gave us an added benefit at this point; because it is possible to add in as many local domains as needed, which allowed us to correct addresses on the fly. The reason why there aren't problems like these on the Internet with standard e-mail is because Internet e-mail is transferred to different hosts by looking them up through a domain name system server. Instead of using an address book (which is always subject to errors), the remote mail server is looked up at the DNS based on the domain where the e-mail is destined. For example, if a message is destined to, the local mail server where the message is sent looks up the first mail server responsible for the domain. The DNS server returns the relevant server name, and that name will be looked up to find the IP address. Once that is found, the sending mail server makes a remote connection to the remote mail server on TCP/IP port 25, and the mail is sent using simple mail transport protocol commands. The Sun workstations powering the ATCCS community use a different process that looks up destination server information based on the local server's preprogrammed address book. Assuming this book contains correct entries, the systems listed should share their data.

Once freetext messages were received, we tried to send information that would be useful to MCS-L: operational graphics, contained in a USMTF S201, and enemy graphics, which we started with the S303. This is where we ran into yet another problem. We started with our system's address built into everyone's address book as an MCS system. The AFATDS quickly returned an error saying that it cannot send graphics to an MCS machine. The RWS said it couldn't send enemy units to an MCS machine. MCS-L is designed to show enemy units and operational graphics; however earlier releases of MCS did not have this capability. We quickly rectified the error by changing the AFATDS address book by changing our system type to RWS, and having RWS set up our system type to RWS. We didn't have the AFATDS set us up as an AFATDS, because AFATDS machines do not use USMTF to communicate with each other--they use proprietary user datagram protocol packet transmissions.

Integration successes

By the end of the week, we could receive operational graphics from AMDWS and AFATDS, and also S303s from the RWS. We built the parser in Cold Fusion since it provided a known (powers 3d ID TACWEB) method to interact with databases. Our Cold Fusion parser downloads the email using Post Office Protocol 3, and parses the message into the information needed to post graphics to the MCS-L JCDB. We also could take the freetext message sent to us, and reverse the "to" and "from" ATCCS alias in the message header, and send it back to the ATCCS machine. This verified the ability to send graphics and possibly the friendly picture to the other machines. The downfall with sending the friendly feed (done with S507L messages) remains task organization consistency. In order for the friendly feed to work, the receiving machine must have a good task organization with all the unit identification code for all units that could possibly be sent. This is due to the message format--it only includes the military grid reference systems grid for each unit, and the unit's UIC. The other ATCCS machines typically did not have the 3d ID's task organization built into their system.

The following example shows two messages sent from AFATDS, and their result on MCS-Light:

Once we ironed out these details, we began our ramp-up exercises for Warfighter. At the final ramp-up exercise, another system that sent USMTF 507L messages appeared: the RTM. The RTM receives changes in the corps battle simulation and converts these to USMTF messages led to every ATCCS machine at the lowest level (typically the battalion level). The purpose of the RTM feed remains in the elimination of the tedious work done at the battalion level, since the Warfighter evaluates the commanding general and staff--not how a battalion operates the ATCCS machines. Although a small controversy started over this process, we continued on our mission to accept the S507L messages from RTM, and parse these messages into the MCS-L JCDB. This process ran successfully during the ramp-up exercise, however the CBS link to RTM had some technical difficulties through out the exercise, which resulted in stagnant units. Also during this exercise, we rewrote the header on the S507L messages, and sent them to XVIII Airborne Corps's GCCS-A machine (3d ID's higher headquarters). This integration requirement arose during the exercise, and we implemented the change at the beginning of the final ramp-up exercise.

We shared our integration efforts with the MCS-L team, and they built a stand-alone parser based on the same principles, but didn't require Cold Fusion to run. They created this parser in order to deploy it to other units, like 82d Airborne Division. The team programmed the parser in Visual Basic and used Microsoft Outlook for the mail client. This parser is currently capable of parsing S507Ls from RTM, and S309 messages from RWS. We initially used the S303 message; however it required the RWS operator to send it manually, which did not occur often enough. The S309 messages can be sent at timed intervals (typically 20 minutes), which leads to greater accuracy of the enemy picture.

The MCS-L team provided an enhancement to MCS-L during one of our exercises. This new capability allows users to view combat power on friendly unit icons. Since TACWEB computes the combat power already, we wrote another query that updated the combat power along with the unit location on the TACWEB overlay. This example shows the need for changing command and control systems on the fly. During an exercise, the commander may realize he or she needs different views of the data in order to truly show combat effectiveness. Command and control systems cannot wait for a requirement to pass through a program manager shop and sent to a contractor for further analysis.

These integration capabilities culminated at the 3d ID Warfighter in 2002. At the Division Main tactical operation center, the Solipsys system (an integrated battle command station) provided the primary view for the commanding general and primary staff, using five computer projection screens controlled by a video switch. Although the screen output configuration commonly changed, the primary views shown during the Warfighter were: TACWEB combat status, MCS-L common operational picture, AFATDS fire support overlay, UAV video feed and AMDWS overlays. The TACWEB combat status displayed a page that refreshes every five minutes that reflects the overall division equipment roll-up calculated from each of the units' Sitreps. The MCS-L common operational picture displayed the friendly units and enemy units, along with the division's operational graphics. The commanding general could choose between seeing the RTM friendly unit feed or the TACWEB friendly unit locations. The enemy feed came directly from the RWS S309 messages parsed at the MCS-L server. The AFATDS fire support overlay and AMDWS overlay showed a direct feed from the primary AFATDS machine in division main tactical operations center. The UAV feed came from a laptop using Microsoft Media Player to view streaming video from the DMAIN network. Microsoft Media Encoder provided the video stream for clients to view. This integrated system provided the commanding general and staff with a fully digitized view of the battlefield, and enabled them to make quick, decisive actions based on timely and accurate information.


Although 3d ID did not field Army Battle Command Systems 6.0 ATCCS machines, we did integrate the crucial command and control systems. CSSCS ran in stand-alone mode, however users could access it through Netscape with the addition of a thin-client. We integrated the other command and control systems in accordance with their design (USMTF messaging), and integrated our TACWEB system as a command and control tool that disseminates information to the lowest levels. The ATCCS systems may work much better together with expensive software upgrades and contractors like those at Fort Hood, however with command emphasis and a lot of technical coordination, we proved that integration could be done with any system that uses 1s and 0s to talk.
System Messaging Type Database Type

AFATDS USMTF 1993 Informix
AMDWS USMTF 1993 Informix
RWS USMTF 1999 Oracle


ABCS--Army Battle Command Systems

ADC(M)--Assistant Division Commander (Maneuver)

AKO--Army Knowledge Online

AFATDS--Advanced Field Artillery Tactical Data System

ATCCS--Army Tactical Command and Control Systems

AMDWS--Air Missile Defense WorkStation

C2--command and control

CBS--Corps Battle Simulation

CSSCS--Combat Service Support Control System

DAMO--Division Automation Management Office

DMAIN--Division Main Tactical Operations Center

DNS--Domain Name System

IP--Internet protocol

JCDB--Joint Common Database

JVMF--Joint Variable Message Format

MCS-L--Maneuver Control System (Light)

MGRS--Military Grid Reference Systems

ODBC--Open Database Connectivity

PM--program manager

POP3--Post Office Protocol version 3

RTM--Run Time Manager

RWS--Remote WorkStation

SMTP--Simple Mail Transport Protocol

SQL--Structured Query Language

TACWEB--Tactical Website

TCP/IP--Transmission Control Protocol/Internet Protocol

TCRIT--Target Criteria

TIDAT--Target Intelligence Data

TOC--Tactical Operations Center

UAV--Unmanned Aerial Vehicle

UDP--User datagram Protocol

UIC--Unit Identification Code

USMTF--United States Message Text Format

CPT Stephen Hamilton is currently assigned to the 57th Signal Battalion S3 and is developing a web-based soldier information system. While he was assigned to 3ID, he spent nine months in 3ID's G-6 Division Automation Management Office before deploying to Bosnia where he developed the peacekeeping version of TACWEB that is integrated with the Balkan Defense Initiative. Upon his return, the majority of his time was spent integrating TACWEB and command and control systems. Previously, he was assigned to 3ID's 123d Signal Battalion as a node center platoon leader. CPT Hamilton holds a B.S. in computer science from West Point.
COPYRIGHT 2003 U.S. Army Signal Center
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2003 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Title Annotation:Army Tactical Command and Control Systems
Author:Hamilton, Stephen
Publication:Army Communicator
Geographic Code:1USA
Date:Jun 22, 2003
Previous Article:Unit of action Network MAPEX: testing the network in a virtual warfight.
Next Article:Warfighter: 10th Mountain Division's winter training exercise.

Terms of use | Privacy policy | Copyright © 2018 Farlex, Inc. | Feedback | For webmasters