STSC Logo About Us Consulting Services CrossTalk STC Conference Resources


Software Technology Support Center


About CrossTalk

  - Mission
  - Staff
  - Contact Us


About Us

Subscription

  - Subscribe Now
  - Update
  - Cancel
  - 


Themes Calendar

Author Guidelines

Back Issues

Article Index

Your Comments
Home > CrossTalk Jul 2004 > Article

CrossTalk - The Journal of Defense Software Engineering
Jul 2004 Issue

The Advanced Field Artillery Tactical Data System Proves Successful in Battle
Pamela Palmer, CrossTalk

While Operation Iraqi Freedom remains ongoing, one initial military success is the operation of the Advanced Field Artillery Tactical Data System (AFATDS) in preventing friendly fire accidents in missions covering hundreds of miles of territory and hundreds of maneuvering combat units. With the AFATDS', robust communication architecture, the entire theatre was provided with a common understanding of the battlefield fire support situation.

One of the U.S. government's software success stories for 2003 is the Advanced Field Artillery Tactical Data System (AFATDS). In Operation Iraqi Freedom (OIF), the AFATDS prevented friendly fire accidents, provided additional protection to friendly forces, and created significant savings in weapon systems and ammunition costs. All this was accomplished through AFATDS' timely and effective fires delivered against enemy targets in accordance with the commander's guidance.

In addition, as specifically noted by Lt. Gen. Steven W. Boutelle, the U.S. Army's chief information officer, the AFATDS has been a model procurement program — on schedule, within budget, and meeting all technical performance standards and contractual delivery requirements.

The AFATDS' greatest contribution in 2003, however, was its outstanding performance by the 600 systems used by the front-line fire support units of the U.S. Army and Marine Corps during OIF. Maj. Gen. Michael Maples, former commanding general of the U.S. Army Field Artillery Training Center, noted in July 2003 that the AFATDS was a significant combat multiplier that helped military units win the war, and prevented friendly fire incidents from occurring during OIF 1.

Overall, the AFATDS has become an integral part of the Army and Marine Corps command and control (C2) network- centric architecture — delivering devastating and accurate fires at the right place and right time. Additionally the system is proving to be a key transformational agent as the Army moves to the future force designs from its current force. While OIF remains ongoing, the AFATDS continues in its role of preventing friendly fire incidents, shortening times for effective engagement of targets, and creating significant savings in hardware and ammunition costs.

The Inner Workings

The AFATDS is a multi-service U.S. Army/Marine Corps automated C2 system for fire support used throughout the battlefield at all levels. The AFATDS provides timely and effective fires delivered against enemy targets in accordance with the commander's guidance. Built from the bottom up, the AFATDS processes, analyzes, and exchanges combat information within the fire support architecture and the joint environment. "It knows where every fire support platform is located on the battlefield, the ammunition status, the range capability, etc.," said Lt. Col. James J. Chapman, product manger Fire Support Command and Control, Ft. Monmouth, N.J. "AFATDS uses a robust communication architecture that provides the entire theatre with a common understanding of the fire support battlefield situation," he explained.

The AFATDS includes interoperability with other Army battle command systems, coalition systems, Marine Corps C2, intelligence and sensor systems, the Air Force's Theater Battle Management Core System, and the Naval Fires Control System. The AFATDS is capable of managing and tasking weapon systems from the joint community, including field artillery cannons and rockets/missiles, fixed wing air fire support, Naval surface fire support, mortars, and Army/Marine aviation (helicopter) attack systems. The AFATDS performs these functions at echelons from above corps down to platoon level.

On the battlefield, the AFATDS provides operators with a complete look at all the engagement target options available to attack a target. "A sensor, such as a human or radar, detects an enemy target to engage as a threat to be eliminated," said Steve Bohan, technical lead at Raytheon. "The sensor submits a digital or voice request to AFATDS, reporting the type of target, location, and engagement instructions. AFATDS compares the target data to commander's orders and available weapon platforms, and develops options for all these different platforms to destroy the target. All options, along with AFATDS' recommendations are presented to the operator for review. The operator can configure AFATDS to make recommendations considering what is important to him: speed of engagement, time, munition, preferences, etc. After the target is engaged, AFATDS tells the operator when the fire is completed, whether to fire more, and the effects reported by the sensor; it then distributes this information across the battlefield."

The AFATDS software provides functionality in four major areas: situational awareness, battle planning, battle management (execution), and fires/effects processing. It provides target analysis and weapon selection logic that ensures that the right munitions are placed on the right target at the right time.

Several Quality Aspects

Quality is critical to the AFATDS since it is being used in war as well as in live-fire exercises where personnel safety is essential. Key to achieving quality is the use of the Capability Maturity Model®, processes, Raytheon Six Sigma, and a comprehensive software cost estimation model. The AFATDS System was developed at Raytheon's facilities in Fort Wayne, Ind. It uses an incremental build approach with a series of sequential releases containing increasing functionality. Each build goes through a full development life cycle, including software requirements analysis, design, code, unit test, and integration.

The AFATDS has been certified to meet safety, security, and Defense Information Infrastructure Common Operating Environment Level 6 requirements. It interfaces with more than 50 different digital systems across the joint spectrum and is required to run on an everchanging series of hardware platforms. The AFATDS has more than 5,000 system requirements and over 8,500 software requirements. These requirements are documented in the System Software Specification, Interface Control Document, and 16 Software Requirements Specifications that total over 9,000 pages.

An extensive configuration control system using Apex and Encompass tools for the software environment assisted software engineers in producing quality code. The DOORS database is used for tracking system and software requirements, and produces bi-directional traceability between these documents and test cases. Engineering change requests are used to control changes to the system requirements, and change orders provide the authorization methods for working controlled software changes.

"Software development tools allow us to have top-to-bottom traceability all the way back to system-level requirements," said Bohan. "Since DOORS is object oriented, we can run queries and get reports on changes, including printouts. It's a good tool for online requirements documents and can search through the 9,000 pages of requirements developed."

Quality measurements are continuously performed and documented in weekly and monthly metrics reports. These reports are generated to track defect density, number of requirements integrated to date, fault correction progress, software changes initiated versus retested successfully, and tasks started measured against tasks completed to date.

"Early versions of AFATDS used traditional waterfall development," said Cynthia Inteso, technical lead at Ft. Monmouth. "As time progressed, each AFATDS version became more complex and since we had an established software product baseline, we transitioned to an incremental iterative build approach." This meant developing a series of builds, each with a small set of requirements. When rolled up at the version level, these incremental builds allowed a more rapid approach of providing quality-enhanced capability to the user in the field.

Another facet of the quality process uses a series of test procedures termed a smoke test. A smoke test is run on each build that exercises the main threads of the system assuring build integrity and software quality early in the development cycle. After code completion, a full integration test suite is run over a 10-week period to assure defect-free software at final delivery. During recent government testing, there were zero priority one or two software defects reported in the 1.8 million lines of code.

Testing was a big reason that a small number of problems were reported from locations in Kuwait and Iraq. "Our processes enforce traceability of requirements through modules and into test cases," said Bohan. The government also runs independent verification and validation, providing a separate set of eyes to review software per criteria, he added. "Testing will often show that a system meets requirements, but then you see additional requirements to add. Everything in this system is configuration managed for complete control and repeatability."

Communication was the main contributor to the AFATDS' quality ratings, according to Chapman. "Quality really links back to open communication between team members, so we were all clear with regard to where we were going."

Combat Success

The AFATDS V6.3.1 software was materiel released to various Army and Marine units in January 2003 and was immediately deployed for use in OIF. This was the first time the AFATDS was used in combat. Raytheon engineers provided support in the conflict zones. Combatinspired enhancements and problems were immediately reported back to Raytheon through various methods via the Raytheon Field Integration Team.

The field engineers provided e-mail problem definitions and information that enabled the Fort Wayne engineers to recreate and debug the problem in a lab environment. Semi-weekly teleconferences with the engineers also helped accomplish problem resolution in a timely manner. The outstanding performance of this software was demonstrated by the small number of problems reported from locations in Kuwait and Iraq.

According to one customer, the return on investment from the AFATDS in performing its stated mission is best measured by the results of OIF.While directing the fires of more than 35,000 rounds of munitions, 857 rockets, and 453 longrange missiles, the AFATDS prevented friendly fire accidents (fratricide) from occurring among its users. The AFATDS' coordination of air space alone allowed friendly fixed- and rotary-wing aircraft to safely and simultaneously engage enemy targets along with friendly rockets, missiles, and land and naval gunfire without the loss of an aircraft due to friendly fire.

The AFATDS has proven itself against the test of time. In the hands of warfighting units since 1997, the program has accommodated its end-users (Army, Marine Corps, and Navy) by incorporating the most current operational techniques, as well as modern technologies. Additionally, the AFATDS program has been a role model for achieving the critical capabilities development, as well as the contractual necessities of maintaining cost, schedule, and performance. The AFATDS' future appears to be as bright and opportunistic as its past, since the AFATDS will clearly be part of the transition to the future fires C2 systems for joint and coalition operations.

Note

  1. AFATDS Media Day, July 2003, Rosslyn, VA.

Project Points of Contact

Cynthia Inteso
PM Intelligence and Effects
Technical Lead — AFATDS System Development
Phone: (732) 532-6004
E-mail: cinteso@c3smail.monmouth.army.mil

Lt. Col. Jim Chapman
PM Intelligence and Effects
Product Manager, Fire Support C2
Phone: (732) 427-3328
E-mail: james.chapman@c3smail.monmouth.army.mil


USAF Logo


Privacy and Security Notice  ·  External Links Disclaimer  ·  Site Map  ·  Contact Us