Engineer digital command and control.
This article addresses the chronology of the Engineer Regiment's efforts to complement Armywide efforts in development and transformation of command, control, communications, and computers (C4). The central requirement is that the future system will serve the needs of the combinedarms commander. Requirements that are more oriented to the engineer staff's needs should be considered as distinct from maneuver requirements. Digital C2 systems will enable the future vision of support to maneuver forces by defining actions necessary to ensure the mobility of the force: see first, understand first, act first, and finish decisively.
With the proliferation, sophistication, and availability of digital technology in the late eighties came the natural impulse to apply digital solutions to battlefield functions. The introduction of systems such as the Standard Army Training System, the Unit-Level Logistics System, and e-mail facilitated broad steps toward unit automation. Engineers sought the same digital efficiency. In the early 1990s, USACE sponsored a Science and Technology Objective (STO) for the Engineer Obstacle Planning System (EOPS), which was a forerunner of the Maneuver Control System-Engineer (MCS-E). TerraBase provided staff officers the capability to quickly analyze terrain and distribute useful terrain-visualization products. SapperNET, developed by the 3d Infantry Division in early 1999, was the first use of the Tactical Local Area Network to post engineer reports to a Web server to share commonly used data. From this legacy, the 18th Airborne Corps developed CastleNET as a Web-based reporting system that could be adapted by a ny engineer unit. The Engineer School developed the Digital Topographic Support System (DTSS) to provide engineer terrain teams at the brigade, division, corps, and echelon-above-corps levels with automated assistance performing terrain analysis and creating topographic products.
Proponents of other Battlefield Operating Systems (BOSs) were simultaneously developing automated tools to assist in collecting, analyzing, and disseminating information relevant to their unique requirements. These included the MCS, Advanced Field Artillery Tactical Data System, and All-Source Analysis System. By the late 1980s, this confederation of BOS C2 systems became the Army Tactical Command and Control System (ATCCS). These systems funneled data directly from source to intended recipients, bypassing the wider community of staffs working to satisfy battlefield demands. This "stovepiping" of data was not originally a problem since it was understood that the staffs would distribute the relevant information. ATCCS had five systems. Since then, additional systems were added as the need for even greater BOS functionality became apparent. The ATCCS evolved into the current ABCS, which now has 11 systems.
The Division Capstone Exercise (DCX), conducted in two phases at the National Training Center, Fort Irwin, California (DCX I), and at Fort Hood, Texas (DCX II), better refined command, control, communications, computers, intelligence, surveillance, and reconnaissance (C4ISR) requirements (see "Assessing Engineer Priorities in the Division Capstone Exercise," Engineer, February 2002). Commanders demonstrated how ABCS provided a common operational picture (COP) and situational awareness that improved efficiency and lethality. While automation has transformed battlefield dynamics, the systems themselves have significant shortcomings.
During the DCX II after-action review/commandant's video teleconference on 5 November, TRADOC Commander, General John N. Abrams, addressed some of the broad issues confronting ABCS viability. Foremost was the observation that all systems lacked integration and were too oriented to meeting individual BOS requirements. He directed the Combined Arms Center Commander, Lieutenant General James C. Riley, to lead an effort to reassess the ABCS and make recommendations to TRADOC on whether to continue program funding, modify the system requirements, or discontinue the program. The following quote from Lieutenant General Riley addressed ABCS way-ahead efforts: "...overarching driver for final recommendations will be the degree to which each system integrates into the combined-arms fight in order to support situational understanding and decision making by combined-arms commanders."
There are distinct aspects of the commander's situational awareness that engineers historically manage. The Engineer Regiment is always cognizant of our fundamental purpose to support the combined-arms commander in the prosecution of the warfight. It is challenging to sort through the myriad of tasks and assign priorities from the maneuver perspective. In one sense, all our activities are oriented to the combined-arms fight, but the question really deals with the specific information the commander needs for decision making. These include preparation for combat, correlation and control of forces, knowledge of the enemy, and the effects of combat action. Many of the current capabilities in MCS are designed to meet the requirements of the battle captain. The commander probably does not need to see an engineer overlay dotted with little green marks; instead, he needs a visual analysis of enemy activity, considering obstacle effort grouped according to probable enemy intent. Similarly, the commander may not under stand the significance of electronically highlighted routes and bridges until he sees how they fit with other aspects of terrain and with the scheme of maneuver.
The current thought is that considering the offensive focus of current doctrine and the emerging emphasis in the Interim and Objective Forces on assured mobility, obstacle situational awareness is one of the most important command requirements. Equally important is the ability of the commander to see the terrain and understand its effects on maneuver. Topographic engineers can provide a variety of digital tactical decision aids and terrain-visualization tools for maneuver support. Other important tasks must be automated as well. Legacy Force doctrine still accounts for defensive operations making survivability and countermobility tracking important in automation efforts. At this stage in ABCS development, various systems give us only pieces of the data sets required to create relevant command decision-making tools.
Maneuver Control System
The aptly named MCS does not adequately support the engineer's ability to package information for the commander. Although the initial requirements documents addressed the need to record and report obstacle information, developers focused efforts on other maneuver priorities and on system stability. Not until operational testing at the DCX did the extent of the deficiencies become clear. Currently, the MCS has no means by which engineers can track obstacles, much less perform mobility analyses. Very little of the obstacle data generated at ground level can be automatically sent to the MCS and, even then, there are no tools to manage and synthesize data into information.
As this system evolves, it must allow the soldier to accurately record friendly and enemy obstacles according to doctrine, post these immediately to the COP, and be able to update obstacle information in real time. Staffs must be able to receive, store, update, collate, analyze, and disseminate obstacle information and graphics up and down the chain in real time. Technically, this requires a database--fully compatible with other hardware and software--empowered with user-defined query capability and "fuzzy-logic" decision aids.
Force XXI Battle Command Brigade and Below
Development of the Force XXI Battle Command Brigade and Below (FBCB2) System, the fightingplatform-level reporting and situational-awareness system, accommodated engineer needs to a much greater extent than did the MCS. At the platform level, obstacle situational awareness is achieved. Obstacles discovered are reported in real time and populate the entire lower tactical internet. The systems in vehicles that are approaching recorded obstacles even give the drivers audible warning. However, during the DCX in early 2001, minefield fratricide became a primary point of command attention.
The FBCB2 System provides three primary message formats that engineers typically use: the obstacle report, the minefieldlaying report, and the overlay message. The obstacle report, intended originally as a means of reporting enemy obstacles, automatically displays the reported minefield on all FBCB2 screens. The minefield report and overlay message are intended for friendly minefields and graphic dissemination of engineer planning. While most of the relevant information is captured in these three reports, a complex combination of work arounds and tactics, techniques, and procedures involving all three reports is needed to push information to the intended recipients. It does not automatically make information digitally accessible to the higher echelons.
To date, the MCS-E program has suffered from a lack of definition and focus within the ABCS construct. Although there has been work since the inception of the MCS to create a stand-alone C2 system, called MCS-E, for the mobility/survivability BOS, those efforts have fallen significantly short of the mark. There is also valid concern in the Regiment that another stovepipe box in ABCS would be a mistake. As a result, the Engineer School decided that MCS-E should be integrated directly into MCS. MCS-E is an effort to assist the TRADOC System Manager-MCS in meeting engineer requirements. It will provide engineers with a seamless, integrated set of tools in one easy-to-use software package. Capabilities will include countermobility, survivabilty, mobility, and sustainment tools. MCS-E will be integrated into the MCSLight System. It will incorporate all of the functionality that currently exists in CastleNET and will have the added benefit of being totally integrated into the ABCS architecture.
It is intended that these tasks identified as most important to the combined-arms decision-making process be addressed by the MCS, while all additional, more staff-oriented tasks be incorporated into MCS-E. Integration of this effort is expected to coincide with MCS, Version 7.0, which is scheduled for release in FY04.
Digital Topographic Support System
The DTSS software is largely successful at the technical level and can be enhanced through software upgrades and doctrine, training, leader development, organization, materiel, and soldiers (DTLOMS) adjustments. Since it is able to leverage commercial software, the DTSS is a fully integrated member of the ABCS family and is a stable, reliable system in the field. Unique government applications provide added functionality to process digital terrain data. System upgrades are delivered to the field as software advances are achieved. Many products can be prepared using the DTSS, including tactical decision aids, slope analyses, intervisibility plots, and 3-D terrain fly-throughs. A map server was added at DCX II to provide a readily accessible archive for larger terraindata files in the tactical operations center. The units performed well at the DCX, but mission performance standards (mission training plans [MTPs]) must be identified to better focus the soldiers on keeping their technical skills razor-sharp.
Joint Mapping Toolkit
The Joint Mapping Toolkit (JMTK) was designed to serve as a common system for terrain-data displays and some embedded-data analysis tools throughout ABCS. Problems with the initial release of the JMTK led to the variety of display software as each system sought its own display tool. There are presently seven different terrain-datadisplay software packages in use within the ABCS. This leads to a lack of commonality in terrain-data representation and functionality. The current version of the JMTK used at DCXII is more stable and capable than previous versions. External interfaces with DTSS and other ABCS members will increase the effectiveness of planning, execution, and reporting by engineer units.
Using the DCX after-action review and consultation with the field, MCS deficiencies have been captured, articulated, and passed on to the TRADOC System Manager-MCS. The MCS-E will give us an opportunity to insert engineer functions into the MCS in its FY04 release and subsequent versions.
The FBCB2 System will release Version 4.0 in FY04 as well. The Maneuver Support Center's (MANSCEN's) Director of Combat Developments is working to refine the message format in the FBCB2 System to fix reporting shortcomings and facilitate database management of obstacles, but it is not yet clear whether these significant message format changes will be reflected in FBCB2, Version 4.0. There are varying degrees of difficulty in effecting changes with proponent, contract/cost, priority, and time considerations involved. A short-term solution involves changes to the existing message formats. The minefield symbol that autopopulates all other FBCB2 screens can be changed to capture the obstacle number; the drop-down menus in the obstacle report can be changed to better reflect obstacle status options; and the ability to edit existing obstacles can be added to circumvent the requirement to send additional messages about the same obstacle whet the status changes. The task is further complicated because changes to the messages and Military Standard 2525B (Fie;d Manual 101-5-1, Operational Terms and Graphics) must be approved by an interservice board.
CastleNET is essentially two subsystems (CastleNET Reports and CastleNET-Visual) that currently require a manual interface. CastleNET-Reports (previously SapperNET) is a Web. based (SIPRNET) system at the task-force level into which reports from lower echelons (mobile subscriber equipment, FM radios, and e-mail) are entered. Standard reports include enemy and friendly obstacles, engineer missions, main supply routes, bridges, and logistics. Once entered, the data is saved to a relational database that self-replicates the data to databases al higher echelons, essentially creating several identical sets of data available for use at each echelon through corps.
CastleNET-Visual is an overlay-producing program used to create situational awareness and update the various commanders' COPs. As mentioned, the transfer of data from the reports database to a current overlay requires a multistep transfer of data on a Global Command and Control System box. Once the transfer takes place (one contractor or trained soldier is required full-time), several other manual data-transfer steps must take place to view the update on the corps COP and MCS-Light (personal computer/Windows-based). At this point, despite the manual processing steps involved (elapsed time 5-60 minutes), obstacle situational awareness is available for the commander's decision-making process.
CastleNET was successfully used during the 18th Airborne Corps Warfighter Exercise in early February 2002. It has received developmental Joint Forces Command funding through the Joint Area Clearance Advanced Concepts Technology Demonstration to determine the military utility of the system. With further funding, CastleNET could serve as an interim solution until MCS, Version 7.0, is released. Incidentally, the MCS-E is using much of the functionality of CastleNET to accelerate its developmental efforts.
The next software release of DTSS in the fall of 2002 will include a capability called battlespace terrain reasoning and awareness (BTRA). This new tool will enhance the capability of DTSS users to provide terrain-analysis products that can be rapidly modified as the battlefield situation develops. Meanwhile, understanding the use of digital topographic products will be enhanced through the development of a new Training Circular 5-230, Topographic Smart Book. This will increase awareness of potential DTSS products in the field and at the TRADOC schools for battle staff officers. There has always been a close relationship between the topographic engineer community and the intelligence community, especially in the use of imagery products. Engineer units in recent years have provided more oversight of topographic functions. This has increased the focus of the topographic units on both the friendly and enemy terrain regions, but some units seldom use imagery products from the intelligence community. The Engineer School is refining concepts with the Intelligence School through the Imagery and Geospatial Information Integrated Concept Team. Conclusions from this analysis will help refine the synergistic relationship between the topographic and intelligence functional areas.
Visualization of terrain data throughout the ABCS will b impacted by a congressional mandate for commercialization o the JMTK. The new commercial JMTK (C/JMTK) contract award should take place in FY02, with initial software release in FY03. Portions of JMTK software can potentially be in corporated into the C/JMTK. The Engineer School will participate in the development of the C/JMTK to manage capabilities and costs associated with software licenses, since thousands of computers will use this system.
Engineer C2 Roadmap
The figure on page 20 shows notional timelines for combat engineer and geospatial C2 developments and a concept for digital systems training at Fort Leonard Wood. The figure shows CastleNET providing current capabilities to support combat engineer tasks; CastleNET will be retired after the MCS-E is delivered. The DTSS will incorporate BTRA in the fall 2002 delivery, with continued software upgrades as commercial industry and government labs build added functionality. The Engineer School will accommodate digital systems training with the advent of these automated systems so that engineer students will see digital systems being used effectively before departing Fort Leonard Wood. MANSCEN assets will be used to show students how the MCS-E, DTSS, and other digital systems are employed.
The Way Ahead
As previously mentioned, the ABCS way ahead was a series of conferences to review, update, and determine courses of action oriented to a final decision brief to General Abrams in early February 2002 to facilitate program Objective Memorandum 04-09 input. The action officer conference methodology was used to conduct a mission analysis to develop a common understanding of ABCS capabilities gain consensus from all stakeholders, and present he recommended courses of action to the TRADOC commander. All viable courses of action address actions to be taken after ABCS, Version 7.0 (MCS 7.0/FBCB2 4.0), to accompany the transformation of the Legacy and Interim Forces. A separate Future Combat System (FCS) C2 capability will be developed for the Objective Force.
The Objective Force concept is still in development. TRADOC is conducting a series of seminar war games to focus senior leaders on fleshing out operational and organizational issues. Other efforts are ongoing:
* A unit-of-action (UA) task force was stood up at Fort Knox during the fall of 2001.
* A full-time working group is exploring the nature and requirements of the FCS.
* Five concept experimentation programs (CEPs) are underway, all oriented on transformation with full engineer participation.
In addition, the Engineer School has done an enormous amount of work exploring countermine requirements and solutions for the Objective Force Assured Mobility Concept.
Assured mobility involves actions that guarantee the force commander the ability to maneuver where and when he desires without interruption or delay to achieve his intent. It presupposes situational awareness through superior battlefield vision and understanding. The commander is able to develop a thorough mobility COP with geospatial products to help assess the environment and see the enemy's intent. With extensive support of sensor webs, he is able to select, establish, and maintain operating areas, from which he sets the conditions to fix and destroy enemy forces and move according to operational requirements. From an operational position of advantage, he can then attack at will, using stand-off detection/neutralization of obstacles. Finally, with the aid of embedded systems, he can breach residual obstacles and maintain mobility and momentum.
When the Objective Force operational and organizational concepts are approved, the current C4ISR requirements will be revisited with the intent of developing an integrated system structured around the needs of the commander. Taking advantage of current and future technologies, the Objective Force commander will have at his disposal tactical decision-making aids, collaborative and interactive planning tools, real--time access to reach--back expertise and resources, and the ability to conduct mission rehearsals on the move. It is clearly vital that MANSCEN and the Engineer School embrace a forward--focused posture to ensure that these systems serve the combined-arms commander with relevant information from the maneuver support community. These capabilities will be facilitated by enhanced engineer C2 systems which will give us information superiority to see first, understand first, act first, and finish decisively!
Major Snyman is chief of the Heavy Forces Division, Maneuver support Battle Lab, Fort Leonard Wood, Missouri. Previous assignments include command of the 535th Engineer Company (CSE), 130th Engineer Brigade, Hanau, Germany, as well as executive officer and platoon leader in the 1st Engineer Battalion, 1st Infantry Division, Fort Riley, Kansas. MAJ Snyman is a graduate of the Engineer Officer Advanced Course and Command and General Staff College and holds a bachelor's degree in English from the University of Kansas and a master's degree in military science from the Command and General Staff College.
Mr. Bergman is the Deputy TRADOC Program Integration Office for Terrain Data, Fort Leonard Wood, Missouri, through July 2002. Previous experience at the Engineer Research and Development Center-Topographic Engineering Center, includes the Rapid Terrain Visualization ACTD, Army Space Technology Office, and terrain database generation. Mr. Bergman is a graduate of the Naval Academy and holds a master's degree in systems engineering from George Mason University. A lieutenant colonel in the Marine Corps Reserves, his experience includes deployments to Beirut and Grenada.