Digitized mapping - the key to achieving a common command and control picture

One of the main goals in transforming the Army is the process of moving away from the use of paper maps and grease pencils into more embedded and computer orientated forms of command and control. There are currently many weapons platforms trying to achieve this function; however, each platform is developing their own solution that meet individual needs. The Army as a whole needs to standardize on a single path forward to ensure that all systems can communicate across the digitized battlefield, allow for each platform will have a "common picture", and promote software reuse across the Army. Once this "common picture" is achieved, our armed forces will have the information needed to continue our domination of the battlefield.


Introduction
Since 1997, the Weapon Systems Technical Architecture Working Group (WSTAWG) has been working on various tasks across the digitized mapping field. The main output of this work is the Weapon Systems Mapping Services Application Programmer's Interface (WSMS API) that provides mapping industry software developers with a common interface to which they can build up their embedded mapping software. Different API implementations will allow a Program Manager to select from various "Commercial off the Shelf' (COTS) products that could meet their individual programs needs. In conjunction with the API, the WSTAWG has also developed a reference architecture for mapping services that provides a framework for interfacing to the application software, and a Map Data Loading Standard (MDLS) that places several standards on the process of downloading the digitized map data to the weapon systems. These activities were the catalyst for the information found within this paper.

The New Millennium
Imagine going to war in this new millennium. During the age of the Internet, with wireless communication at an all time high, the commanders are still using paper maps and grease pencils to create their operational plan. This, however, has been exactly the case in every war or engagement that our country has participated in, going all the way back to the Civil War. If a conflict were to arise today, the commanders would still have little or no common digital capabilities embedded inside their weapon systems.

The Not So Distance Past
distributed to the key leaders during Commander's/Staff Calls. At this time, a transparency was placed over the paper map and grease pencils were used to draw operational symbology and orders on the map as an overlay. This was true to a certain extent in "Operation Desert Storm", where a majority of our losses incurred during the conflict were from fratricide or "friendly fire" by our own systems or our allies. This was due to the fact that our weapon system commanders had little or no real time look around the battlefield. Once the engagement started the commanders simply proceed using the technology that they have at their disposal, to the best of their abilities. During the heat of battle, some mistakes will be made, which is by no means the fault of the soldiers inside the weapon systems. It is the responsibility of the weapon system designers and program managers to ensure soldiers have the most current information on their engagement area, and the location of the surrounding units (both friendly and enemy). This will then lead to soldiers having the most advanced systems on the battlefield and the most up to date information at their disposal.
In the past, paper operational maps were U.S. Government work not protected by U.S. Copyright.

4.D.1-1
The Present leaders decided that something needed to be done to ensure soldiers had a better understanding of what was happening in their vicinity on the battlefield in real time. A few efforts were undertaken to give the weapon system commanders a better operation picture and more information prior to firing their weapon systems. Some of These efforts included the Battlefield Combat Identification System (BCIS), Force XXI Battle Command Brigade and Below (FBCB2), and the Commanders Independent Thermal Viewer (CITV).
Both BCIS and the CITV were developed to help reduce fratricide during battle. BCIS allows the commander to quickly detect if an entity is a "friend" or "enemy" system using a point of engagement, millimeter wave radio, question and answer system that will greatly reduce (95% probability of success between 150-5500 meters) the fratricide risk to friendly ground platforms and dismounted soldiers. During the engagement the CITV gives the commander a better view of the battlefield at night or during other inclement viewing conditions. Both of these systems improvements are beyond the scope of this paper, but were included in order to give a broader scope of the current situation. They emphasis what is being undertaken at this time to ensure losses due to "friendly fire" are reduced in future engagements.
The Program Manager (PM) for FBCB2 is the primary office that is responsible for the development of the Applique system currently being used for the Command and Control (C2) functionality in the Army's weapon systems. The Applique system is basically a ruggedized laptop computer that will have the FBCB2 software, digital map data, operational orders, and overlays loaded inside of its memory. It will also allow the user to format and distribute Joint Variable Message Format (JVMF) messages to be sent out on the tactical Internet through the use of the platform radios. The applique system is being integrated across all of the digitized vehicles in the legacy fleet. At this time the new systems that are being developed are not planning on using the Applique system in its current configuration, they are leaning towards a more embedded solution. An effort currently ongoing the Integrated Combat After "Operation Desert Storm", Army Command and Control (IC3) which has a subset of the FBCB2 software applications running on a Solaris card, in its own separate Line Replaceable Unit (LRU), for both the Abrams M1A2 SEP and Bradley M2A3.
Even with the IC3 solution and the use of the Applique system across the legacy fleet, there are still many issues that need to be examined in order to reach a common solution. The main issue being examined at this time is developing an Army wide common method for disseminating the digital data to the platforms from the Tactical Operations Center (TOC). There currently is a draft operational concept document that recommends a process for those systems using the IC3 solution, or an Applique system. The dissemination to the rest of the systems is currently being discussed, but no real progress is being made at this time. The draft concept describes the use of a Mission Data Loader System (MDLS), which consists of both hardware and software components. The software will reside on the Digital Topographic Support System (DTSS) inside of the TOC. Using the DTSS, the MDLS software, as well as CD-ROM's provided from the National Imagery and Mapping Agency (NIMA), mission data sets will be created and downloaded to a particular hardware device. This hardware device is still under investigation at this time, but will need to have a capacity of at least 1 GB. The hardware device containing the digital data will then be disseminated to all of the FBCB2 systems via "Sneaker Net", a Universal Serial Bus (USB) port will be required on all the platforms so the mission data set can be download into the platforms memory. The mission data set will include the following five major data types: mapping data, passwords, unit task orders, command and control messages, and software patches. The mapping data portion of the mission data set will consist of the following NIMA data products; Vector Product Format (VPF), Compressed ARC Digitized Raster Graphics (CADRG), and Digital Terrain Elevation Data (DTED). Having passwords, unit task orders, and software patches included in this mission data set raises many additional concerns, including security issues as well as the potential need for an additional safety release after a software patch has been added to the platform. The plan mentioned above was demonstrated during the Division Dissemination from TOC to the platforrms

4.D.1-2
Capstone Exercise (DCX) in March 200 1 to ensure that it was valid, during DCX Iomega ZIP drives were used as the dissemination devices. This is a very short-term plan as a common solution across the entire Army is still the desired long-term solution. This long-term solution also needs to address some additional functional requirements including system to system transfer of digital map data, as well as the new digital data types that NIMA plans to provide in the future (e.g. Foundation Data). The short-term solution mainly addresses the concerns from a ground vehicle perspective; Aviation and Soldier have additional hardware and software solutions that are completely different from the MDLS system described previously, and will be described in the following paragraphs.
The Aviation community uses the Aviation Mission Planning System (AMPS) to create the mission data sets that its platforms receive. The AMPS is a stand-alone system that uses NIMA CD-ROM's and a platform specific hardware device to transfer the digital data. The main problem with the A M P S system is that each aviation platform uses a different hardware interface (e.g. PCMCIA card, proprietary device) to download the data it needs from the AMPS system. The AMPS system also outputs some of the digital map data in a proprietary format and not in the standard NIMA format. These issues are currently being worked, and a "common" AMPS solution is under development.
The Land Warrior system also currently has its own solution for disseminating the digital data that it requires. It is mainly a software solution, which will need access to the NIMA data that resides inside the TOC. This software system will extract the desired area of interest from NIMA digital map data, and combines it with other operational data such as Signal Operating Instructions (SOI), Unit Task Orders (UTO), and operational graphics inside a compressed file. Once the compressed file is created it will then be transferred by a direct Ethernet connection to the leaders inside the TOC. These leaders will then transfer this data to their subordinates in a face-to-face Ethernet transfer. Once a soldier has received the data, he then has the capability to transfer this data to another Land Warrior system. This process allows for an entire company to have the same digital mission data set in less than forty-five minutes.
The common dissemination process to the platforms should consist of the following three-step process: initial dissemination, dissemination of updates, and feedback from the field. The initial dissemination occurs prior to the platforms being deployed. Updates will then consist of higher resolution data, as well as changes to the initial data as a result of the ongoing conflict. The feedback step is still being examined at this time. However, the objective is for the platforms to be able to send terrain updates from their engagement area (e.g. blown bridges, minefield) back to the TOC, so that the update can be disseminated to the rest of the platforms.
All of the map dissemination efforts described previously have all been from the TOC down to the individual platforms. Getting updated versions of the required digital map data inside the TOC is a completely different issue that is currently being addressed by the Training and Doctorate Command (TRADOC) Program Integration Office -Terrain Data (TPIO-TD), and the Program Executive Officer for Command, Control, Communications Systems (PE0 C3S). TPIO-TD is acting as the executing agent, and PE0 C3S is acting as the primary system developer. The current concept uses the Global Broadcast System (GBS) satellite network to disseminate the digital data from the national agencies down to the TOC via the Theater Injection Point (TIP). The TIP will be located at Division Main (DMAIN). Once the data is received it is then routed to the Digital Topographical Support System (DTSS) located in the DMAIN. The data is then stored in a Redundant Array of Independent Disk drives (RAID) system for further dissemination. At this point, the DMAIN DTSS device will manage all of the digital data for the command post. The TIP in DMAIN then has the capability to use the GBS to send the digital data to both the Brigade and Battalion TOC's. A graphical representation of this process is shown in Figure 1. The Future situation described above, it is evident that everything currently used for dissemination of digital data is an assortment of various s o h a r e and hardware solutions, most of which are very immature at this time. If this course of action continues, the gap between the different platforms will continue to widen, and a common solution for the entire Army will never be achieved. Currently all of the platforms are working toward solutions for their short-term problems and issues, while no one is examining the much larger and much more difficult development of a common long-term solution. The WSTAWG has taken some action to attempt to provide the platforms with a path forward, but there needs to be a commitment across the Army for a common solution to work.
TPIO-TD and PE0 C3S have a very well defined system in place for the dissemination of common digital data down to the TOC level. In the future, the only potential improvements to their system will be larger disk drives in the RAID devices to store From the descriptions of the present the ever growing amount of digital data and perhaps a replacement to the GBS system. Technological improvements might also be possible as newer digital radios emerge and the amount of bandwidth increases. This increased bandwidth may eventually allow for the digital data to be transferred over advanced radios. However, it is very risky to assume that we can reach the bandwidth goals that we will need in the future, considering using the current radio technology and bandwidth limitations, it would take days to transfer the amount of data that is being projected for the future.
The first step that needs to be taken in order to reach a common solution is for the platforms to agree upon what information will be contained in a Mission Data Load (MDL), and what directory structure this data will be contained in. This MDL could potentially consist of mapping data, passwords, unit task orders, command and control messages, software patches, and any other digital information that will be needed at the platform level.

4.D.1-4
The Map Data Loading Standard (MDLS) [3] that was developed by the WSTAWG could serve as a great starting point for the common directory structure. This standard contains a very rudimentary directory structure, that was developed for the dissemination of digital map data only, this directory structure can be found in Table 1. The directory structure could be updated to include the additional information that would be included in a MDL, as well as to include the future map standards that were not developed when the standard was released in February of 1999. The future directory structure will have to be created in such a way that the platforms can access only the data that is essential for their specific task, while ignoring the data that they have no requirements for. For example, an Aviation platform would have no need for DTED Level 5 (lm post spacing) data, while the Land Warrior system will find this data very relevant. CADRG DTED Level 1 or 2 A common directory structure will also assist in another issue that needs to be addressed. The Land Warrior system has a requirement to be able to download a MDL from the systems that transport them to their engagement areas (e.g. Bradley). If the transport platform does not change the directory structure of the MDL, then the Land Warrior has the potential to access it directly without any additional hardware or software components. This holds true unless the amount (size) of data that the transport platform has is too large for the Land Warrior system to use, which is true in almost every case. The transport platform will need to have the ability to manipulate the MDL information down to the size required by the Land Warrior system that it is deploying. The next step toward a common solution is the development of a software package that can be used to create the MDL for all of the Army systems. This software package will need to be developed to be very scaleable so systems can remove the portions of the software that are not needed to meet their systems requirements. This would mainly come into play when the software is being used to manipulate the digital data on a platform, and not inside of the TOC (e.g. Bradley editing data for the Land Warrior). If this common software solution is developed to meet the requirements of all of the platforms, it could replace all of the short-term software solutions that exist today. The main issue is assigning this development task to a particular Army entity, and then agreeing on the complete set of requirements for the common software package.
Once this software solution is in the development process, all of the platforms will need to agree upon the common dissemination device that will be used to transfer the MDL from the TOC's to the individual platforms. There is the potential to use the future radios to transfer the digital data, but I believe that this is very risky to assume that we will have the required bandwidth to transfer the evergrowing amount of digital data in the future. Once the device is selected, each platform will have to decide if one device will be used to load only one platform, or if the device can be used to load multiple platforms. The use of a dissemination device to transfer the data fiom the TOC's to the platforms brings to fruition numerous additional issues that will need to be examined. These issues include how to replicate the device, the security of the device, the disposal of the device, and of course the acquisitioxdpurchase of all of the hardware and software devices needed for the dissemination.
To promote software reuse, and allow for a "common look and feel" for displaying the digital data, the display interface to the soldier needs to be standardized. The Weapon System Mapping Services Application Programmer's Interface (WSMS API) [ 13 that the WSTAWG has developed is a great starting point for such an effort. The WSMS API provides a standardized interface to a set of mapping and mapping-related services to be utilized by weapon systems applications in the presentation, interaction, and maintenance of Common Display Software

4.D.1-5
Command, Control, Communications, and Intelligence (C3I) data. In addition, the API has been specified in a scaleable, extensible, language matrix data (e.g. DTED), vector data, as well as fix the deficiencies found in the earlier versions of the API.

Symbol
I Overlay 1 1 independent manner such that it can be tailored to application specific requirements (e.g. level of functionality, programming language, etc.). This results in an increased potential for software application reuse across the Army. The WSMS API defines the detailed concepts, functionality, and interfaces required to support the development of both WSMS implementations and applications. In addition, the WSMS API addresses underlying architectural support issues of embedded real time systems such as multitasking, reentrancy, and blockindnon-blocking execution in order to designate the manner in which the WSMS is expected to operate within a weapon system application environment. The current version of this API was released in January of 200 1 , but there is a current effort to update the API to include The components identified in the API and reference architecture are subdivided into foundation and extension components. A pictorial representation of how the foundation and extension components relate to one another can be found in Figure 2. Foundation components are generally abstract in that they provide a template for a base set of functionality common to an overall set or class of like components (e.g. maps or grids). In some cases, foundation components are specified such that they are concrete and can be readily used within an application program. Extension components complete the foundation components by providing the necessary definition to achieve a specific component capability (e.g. CADRG maps or UTM grids). There may be multiple extension components defined for any foundation component.

. WSMS Component Representation
Since the initial release of the WSMS API, the WSTAWG has also developed the Reference Architecture for Mapping Services API in Weapon Systems Domain [2] document, which presents the reference architecture for the WSMS API. The purpose of the reference architecture is to provide a framework for developing the standardized methods for interfacing application software to the various map display subsystems that are integrated within embedded weapon systems. This reference architecture will be used as the basis for developing the future version of the WSMS API. The mapping services called out in the architecture focus on the presentation and interaction of any graphical elements that can be shown on a georeferenced display. This includes, but is not limited to, map data, grid lines, symbology, and a self-vehicle representation indicating the weapon system's current location. These mapping services are designed to support general-purpose embedded real-time map display systems. Specific weapon systems requirements are not presumed in this architecture such that the map server must have detailed military knowledge of the system's environment. An example of this is that the map server will not include the capability to display a prediction for where a particular enemy might be in a time period. Rather, it would be up to an application to perform this calculation and interact with the map server (through the API) to display the prediction. Additionally, this architecture is not meant to dictate how a particular implementation will be developed nor should it constrain a particular implementation in any way such that it cannot meet a weapon system's real time platform constraints and requirements.
The idea behind the development of a common API is to allow different commercial mapping product vendors to develop their products to adhere to the API. A Program Manager can then select the commercial product that best meets the needs of their program. The API is written so that a vendor can develop their implementation with its "base" group of foundation components, or system, as small as possible. In addition different extension components can be added to the "base" system as needed. If all of the vendor solutions are written in the same manner, then it is also assumed that the extension components from one vendor can be added to the "base" system of another vendor and vice-versa. This will lead to a common solution for displaying digital map data across all of the Army's platforms, and would greatly increase software reuse in the mapping arena. A long-term result of this reuse would be substantial cost savings for the Army.
Another issue that needs to be examined for both the future systems as well as the legacy systems is the development of Foundation Data, Mission Specific Data Sets (MSDS), and Foundation Feature Data by NIMA. Foundation Data consists mainly of DTED data, Controlled Image Base (CIB) data, and Foundation Feature Data (FFD). Foundation Data will serve as the base for densification and for the addition of new categories of information. FDD comes in Vector Product Format with feature categories and attribution data associated with these features. The feature density

Future Digital Map Data Types
is dependent upon the specific geographic region, though it will generally approximate that of a traditional 1 :50,000 to 1 : 1,000,000 scale map. FFD will also include delineation of transportation and drainage networks, geodetic control points, populated places, boundaries, vegetation and natural and cultural features of high interest or visibility. MSDS will consist mainly of DTED data, Digital Topographic data (DTOP) and CIB data. MSDS will be developed to include higher resolution controlled imagery, elevation and/or depth information and vector features required to meet and update defined mission requirements.

Command and Control Information
Once there is a "common look and feel" across the mapping systems on the battlefield, we need to ensure that everyone on the battlefield is looking at the same "common picture" of the battlefield. This is slowly but surely coming to fruition, with the development of FBCB2 and its software only counterpart, Embedded Battle Command (EBC). Although EBC has gone through a series of speed bumps, between the ground community's IC3 effort and the Aviation community's desire to revive EBC for use in their embedded systems. If and when EBC or an equivalent is developed, it will be the final piece needed to fully embed the command and control systems.
In the future both the mapping display software (an implementation of the common API previously described), and the EBC software will reside on the same embedded processor card, inside a common LRU. This LRU will operate all of the command and control functionality that the systems need. These functionality's range from displaying the map background on the appropriate display, to sending out JVMF messages to the other platforms on the battlefield, as well as everything in between. The technology needed to accomplish this effort is by no means a stretch from current system capabilities, but there is certainly some additional development and associated risk involved.

Conclusion
The Army has come a long way from the past when commanders were using grease pencils and paper maps. However there are many issues that need to be resolved in order to reach a totally embedded command and control system as a

4.D.1-7
common solution for the Army. We have started in the right direction, but some major hurdles still exist in the path forward us. This common solution is not a simple task that can be done by one individual or one particular PE0 or PM office. In order to achieve the most beneficial and cost effective solution for the Army, every Program Manager and platform developer that has a requirement for digital data will have to be involved in the process. The WSTAWG community has developed a good base for some of these tasks, but a much broader audience is needed to examine the work already completed, as well as the more difficult steps required to complete the process. At that time the Army can ensure that future weapon platforms, and the soldiers that use them, will have the information at their fingertips to have the most dominate systems on the battlefield.