Map Objects/Visual Basic User Interface with UNIX Oracle Database - Our Mission Planning Software

The Special Operations Force Analytical Modeling System (SOFAMS) application is used to plan missions in support of our illustrative planning scenarios. This application populates and maintains large Oracle tables using Esri MapObjects to provide geo-spatial orientation for data input and analysis. Client Visual Basic software builds database entries and allows data manipulation and validation. Final analytical products are extracted with Arc View, MSAccess, MSExcel, and Primavera Project planner. These extraction tools produce graphical, time and spatial representations of the data entered. Future development will focus on simpler extraction interfaces and increased data entry automation. This paper discusses the overall SOFAMS system architecture, time savings realized in the data entry process, design and problem solving issues.

Introduction 
 

The United States Special Operations Command provides resources to support regional commanders and ambassadors throughout the world with unique capabilities for disaster response, peacekeeping,  military operations, and other operations across the spectrum of conflict. Every other year, funding is requested from Congress. The needs are based on long range defense planning guidance from the President and Congress. Strategy requirements are tracked all the way down to the mission level using a "strategy to task" methodology.

From the defense planning guidance, illustrative scenarios are developed, which are refined further into Concepts of Operations (CONOPs). The Special Operations Force Analytical Modeling System (SOFAMS) is a tool that enables operational analysts to enter and analyze the CONOP data.

Special operations units are "joint" forces, meaning that some Army, Air Force and Navy units become part of the Special Operations Command. The variety of unit types makes analysis and common tool development a challenge.

This paper attempts to describe the geospatial information system (GIS) portions of our SOFAMS suite of tools to solicit new ideas and products to integrate into the SOFAMS toolset. Several models do not use GIS in its calculations. While these models are mentioned in the paper, they are not fully discussed here.
 
 

Design/Architecture of SOFAMS 

1. Oracle Database:

 
2. Map Objects User Interface:

 
3. Process Addressed by SOFAMS Software:

Part of the challenge for building SOFAMS came from the fact that Special Operations units are "joint" forces, meaning that some Army, Air Force and Navy units become part of the Special Operations Command.  The variety of unit types (and therefore some of the SMEs) makes analysis and common tool development a challenge.  The user interface is tailored to eight different "looks".

 
4.  Force Structure Generation:

Stage One – Data Entry and Modeling:

1. Four-Tiered Data Modeling:

Initially, ground forces (maneuver units) are entered into the database. Ground forces within our context are Army Special Forces, Rangers, Civil Affairs, Psychological Operations and Naval Special Warfare units. These units are considered the first tier (maneuver model) of the modeling effort. The second tier (mobility model) forces support ground force elements to enable its operations. Second tier missions consist of air force and maritime craft lifting units to and from missions. The third tier (the refueling model) supports the second tier air missions. The fourth tier (C4I model) is the command, control, communications, computers and intelligence (C4I) required for all maneuver and mobility units. The logistics model is an ancillary model that uses information from all tiers to determine logistics requirements for all missions of all unit types.

1. Tier I: Maneuver Data Entry

SOFAMS includes the following consortium of applications to perform Joint Mission Analysis; Visual Basic/Map Objects (Data Entry Forms), Arc View (spatial analysis tool), Primavera Project Planner(temporal analysis tool), and Crystal Reports (ad-hoc reporting).

Each of the six major unit types and platforms within the command has a unique form for the entry of individual CONOPS into the database. They include:

1. SO (Rangers, Army Special Forces, SEALs, Aviation Stand-Alone, and Maritime Stand-Alone)
2. Civil Affairs
3. Psychological Operations (PSYOP)
4. Air Lift Model
5. Tanker (Air Refueling) Allocation Model, and
6. Maritime Lift Model.

Each form is oriented to an individual event in the scenario and contains specific details that normally define a CONOP (mission statement, mission location, travel to mission (called infil), resupply, departure (called exfil), tasks to be performed, etc. SOFAMS data entry maneuver forms upload each of these missions with a unique CONOP number into the JMA database.

 

Data Entry Form:

SOFAMS contains tabbed data entry forms to save/organize screen real estate. This functionality allows data entry in an order best suited to the user.

The menu contains two main functions: File and Features. File|Exit will close the application. The Features menu item allows the user to display feature layers containing: drainage (rivers, lakes, etc.), airports, heliports, reefs, bridges and tunnels, cities, utilities, roads, railroads and more. These options are toggled as the user needs them and they can be shown simultaneously (i.e. bridges and tunnels with drainage). These shape files are located on a server since they rarely change and can be used by any SOFAMS user on the network. Most of these features shape files are derived (via Esri Arc View) from the NIMA Digital Chart of the World.

  

The mechanics of entering a CONOP are relatively simple. The form shown in Figure 2 is initially loaded with the menu save button and all tabs disabled. This allows for proper navigation through the process of entering a CONOP. The user uses enabled choices from the upper portion of the form (scenario, mission area, etc.), then clicks a point on the map with the mouse. When the map CONOP location is selected, a dot appears on the map signifying the location of the mission. In addition, formerly disabled tabs and menu buttons are enabled. The map area is a standard map object manipulated by Visual Basic. The user may enter and save data at this point. Standard mapping operations such as zoom in, pan and zoom out are provided via menu buttons on the top of the form.

Figure 2.  SOFAMS-SO Data Entry Form

1. Technical Details

When the user starts the application he sees a large map of the world. He then moves to the area of interest on the map using the zoom in/out and pan buttons. When the user clicks the Zoom In button, the zoom in icon appears on the map and he draws a rectangle enclosing the map extent that is to be displayed. The application executes the DrawRectangle method. Upon completion, if the area is not 0, the map extent is modified to the rectangle placed on the map. To pan, the user toggles the Pan button. The application displays the pan icon and executes the map Pan method. To zoom out, the user clicks the zoom out button and an extent 5 times larger than the current map extent is displayed on the map.
 
 

The map is composed of several layers. Layer 0 contains the land and water map features displayed in Figure 2. The country name is stored in the shape file for use by the application. The next layer contains all the mission locations or targets in a point map layer. The feature data for the target layer includes the shape, target name, type, task and phase. Each unit type (Rangers, SEALs, etc.) has a separate layer. This design is to allow analysis by unit type; displaying each unit as a separate color on the map display. Layers are stored as shape files and are used in Arc View for subsequent analysis and display. Each unit type layer contains the characteristic unit shape field and a CONOP Number field. The CONOP number field relates the shape file data to the Oracle database tables.
 
 

To add a mission or CONOP, the user presses the Add button. A cross hair cursor appears when the cursor enters the map area. The user then clicks the left mouse button on the map where the CONOP is to take place. The country name is collected from the land and water layer and displayed on the form location tab. Each CONOP is assigned a unique identification code (the CONOP number) that is generated and displayed on the form. A tolerance distance of 100 seconds is then calculated for the current map scale. This tolerance is then used in the map SearchByDistance method on the target layer to collect the closest target to the mouse click location. If a target is within the tolerance distance, the target name is read from the target shapefile and displayed on the form target tab. If no target is within the tolerance distance, a dialog box is displayed to ask the user if a target needs to be added. If so, the user fills out a series of questions regarding the target and a target point is added to the target shapefile and subsequently displayed. The target location LAT/LON is then displayed on the form location, Infil, Resupply and Exfil tabs. A yellow dot is then displayed on the map. This dot is added to the tracking layer once the target location is determined by the visual basic code. The user then enters all remaining required data into the form.
 
 

To save a CONOP, the user clicks the save button. Any CONOP that was added or that was queried or selected will be saved. Before saving, the CONOP is highlighted by a yellow point. Once saved, the tracking layer point is removed, and the new point is added to the appropriate layer for its unit type. For instance, if an Army Special Forces mission was added, the mission location is represented by a yellow dot before the save button is pressed. Once saved, the yellow dot is removed from the tracking layer and the corresponding red dot is placed on the Special Forces layer with matching removal and insertion in the appropriate shape files; essentially turning the yellow dot into a red one.
 
 

To edit a CONOP, the user has several options. To select the CONOP on the map, the user clicks the select button, requests a unit type, then clicks a unit location on the map. As in the add function, a distance around that point is searched for targets. In this case, there may be several units of the same type on the same target. If so, a dialog box appears requesting the user to select the CONOP number to be viewed. The database is then queried by CONOP number and the data is displayed on the screen. If there was a single CONOP on the target, no dialog box is displayed, the database is queried and data is displayed in the form as described above. The map may become extremely busy with dots of various colors in many locations on the map so the selected point flashes four times to alert the user that the CONOP selected is at the appropriate location. Additionally, the point is also added to the tracking layer and remains yellow until the CONOP is saved.
 
 

Another method of editing a CONOP is to click the Query button on the form. The button pops up a textbox allowing the user to enter a CONOP Number into the form. Then the system queries the database for the CONOP and displays the data on the form. The location of the CONOP is flashed four times and the location is written to the tracking layer which turns the point yellow. The user must click the save button to save any changes.

 

The Cancel button allows the user to end a select or query session without saving changes.

 

To delete a CONOP, the user clicks the delete button, then places the cross hair cursor and chooses the CONOP to delete. Again, the SearchByDistance method is used to find the target layer points closest to the mouse click. If there is more than one CONOP on the map at that location, a dialog box allows the user to select the proper CONOP to delete. After the user confirms the choice, the CONOP is deleted from the shapefile and the database.

 

Copying CONOPs became important when identical CONOPs needed to be executed at different targets or at different times during the scenario. All data from the original CONOP is copied to the new CONOP with the exception of the CONOP number and LAT/LON information. The user clicks the COPY button, then selects the CONOP to copy from. The SearchByDistance method is used to find the target as before. The new location is then clicked on the map. The target is then added to the target layer and the new LAT/LON and CONOP number are added to the target shapefile and input form. The new target location is also added to the tracking layer and the location is highlighted with a yellow point. The CONOP data is available for modification and must be saved using the save button.

 

If several users are entering the same unit type data from different computers at the same time, the CONOP locations on maps of both users will not be kept current because the shape files for each user reside on the local computer hard drive. However, the database CONOP locations are kept current. The refresh button is used to remove all target or mission points from the map and refresh the map with new points from the Oracle CONOP LAT/LON table. Each user clicks the Refresh button, selects either target or mission location then views an updated map display.

 

The C2 button allows users to define the command and control (C2) architecture for the missions for the selected unit type.

 

The Chart button allows users to display their level of effort as they are entering their CONOPs into the database. The ultimate purpose of this tool is to minimize the force structure for each unit type and meet all targeting requirements. This option displays a bar chart that shows the resources deployed by day.

 

Civil Affairs and Psychological Operations forms operate in a similar fashion but store different types of data than the SO form. The initial architecture of the forms was to design a single form with SO, CA and PO on separate tabs. The limitation of 256 controls on a single form required each application to be broken into separate data entry forms.

 

Another mechanism to provide information to the user is to right click the mouse button on a target. A dialog box displaying the target name, phase and core task is displayed.

 

2. Tier II: Mobility Platform Modeling

Once the maneuver CONOPs are entered into the database, aviation and maritime mobility platforms must be entered to support identified missions. Specific entry forms have been designed to enter into the database aviation and maritime infil, resupply, and exfil requirements for each maneuver CONOP. The mobility platform data establishes support requirements, mobility task requirements and aviation/maritime mission profiles.
 
 

The objective of the aviation model is to assist in the speedy selection of the best aircraft for the mission at hand and minimize the number of platforms required. The aviators are always hurried because they must wait until all ground unit missions are entered (usually that puts them near the deadline time) before they can begin their data entry.

  

The aviation modeling process begins with flight planning shown in Figure 3. Routes are planned to targets using a PC version of Special Operations Force Planning and Rehearsal System called Combat Flight Planning Software (CFPS). The SOFAMS model reads the CFPS data directly into the database saving route distance data.

Figure 3.  CFPS Route Screen

 
 
 
 
 

These routes are then displayed and verified by the user on the map shown in Figure 4. Time and threat calculations are also performed. Each infil, exfil and resupply CONOP that requires air support must have an associated air route.

Figure 4.  Aviation Routes

The user navigates to the mission by selecting a CONOP to service shown in Figure 5. The detail CONOP information is shown in Figure 6.

Figure 5.  Aircraft Platform Summary Form
 
 

Figure 6. Aviation Model Detail Entry Form

The model then recommends the aircraft that can perform the mission based on threat, distance and cargo load limitations. The darkened rows in Figure 7 contain aircraft that are eliminated because of threat, distance, etc. The white rows contain aircraft that can perform the mission. The user selects the best aircraft for the particular mission type.

Figure 7.  Platform Selection Form

After all aircraft have been selected, an aircraft optimization is run to reduce the number of aircraft necessary to complete all air lift requirements. This process is called sortie linking because separate sorties are linked together in the database, forming a single sortie requirement. After all aircraft have been selected for all missions, there are some missions that are performing an infil and an exfil on the same day. One sortie can be eliminated because the same aircraft performing the infil can also perform an exfil mission. Furthermore, resupply, tankers and PSYOP missions entered into the database can also be linked. Generally, aircraft performing the same type of sorties can service multiple locations. Again, the database is initially loaded with a single sortie for each resupply, tanker and PSYOP requirement. The resupply, tanker and PSYOP linking process eliminates sorties in favor of performing a single sortie servicing a specified number of locations within specified distances of each other.

The maritime model uses ground mission data to allow calculations on distances, threat, sea state and time to and from the target. Boats are used instead of using aircraft to lift ground troops to the target.

1. Technical Details

 

 

Aviation
The aviation model reads in CFPS data as distances between waypoints. Both rotary wing (helicopters) and fixed wing aircraft routes are planned by the aviators. The fixed and rotary wing waypoints are stored as point shapefiles and lines between waypoints are stored as line shapefiles. As the CFPS route is read into the system, the waypoints and lines are added into the shapefiles. The route distances are summed and written to the Oracle database. The routes are displayed on a map by phase of the scenario. The aviation analyst then assigns a general threat level to a set of routes. This data is also saved to the Oracle Database. The threats and distances are then used to calculate which aircraft can perform the mission.

Refueling is a major consideration for the aircraft selection. If refueling is required and the aircraft is not air-refuelable, it is eliminated from consideration. The aircraft are selected by the aviation analyst, not by the model. Each aircraft in inventory is displayed on a grid with detailed information such as the number and type of refueling, plus times and distances as shown in Figure 7. The model will highlight those aircraft that cannot perform the mission.

The INFIL/EXFIL sortie linking process begins by selecting all infil and exfil missions in the aviation database. If they occur on the same day with the same aircraft type, cargo load and LAT/LON coordinates, the missions are linked.

The Resupply sortie linking process begins by querying the database for all resupply missions occurring on the same day that have not been linked and displaying those locations on the map. The first record is selected and a SearchByDistance method is executed to search a specified distance for other resupply missions. The specified number of closest resupply locations are then linked to the first resupply record. This process repeats for every resupply mission in the database.

The PSYOP sortie linking process is identical to the resupply process. The difference being that the database is queried for PSYOP records instead of resupply records.

Maritime
The maritime model uses ground information to populate its tabs. The user selects from a list of missions as shown in Figure 8. The mission detail information is shown in Figure 9. Boat selection can be made by the analyst from this information. With the additional distance data provided by MapObjects, a further refinement of boat requirements can be completed.
 
 

Figure 8.  Maritime Summary Form
 
 

Figure 9.  Maritime Detail Form

The analyst clicks on the Calculate Distance button on the maritime detail form shown in Figure 9 and a map appears as shown in Figure 10. The pan and zoom features work in the same manner as the SO form. To calculate distances, the user simply clicks the Add menu button, then clicks on the waypoints on the map. As the waypoints are clicked the MapObjects DrawLine method is executed. Double-clicking the line calculates the total distance of the line. This calculation is completed by executing the DistanceTo method for each mouseclick location on the map and summing the segment final distance on the double mouseclick.

Figure 10.  Maritime Route Distance Form

The distance equation used in the aviation and maritime models is a version of the great circle route shown in Figure 11. The great circle route is used when platforms travel great distances and need to consider the curvature of the earth in its distance calculations. The code calculates the distance between two points and returns the distance in nautical miles. The unit of measure may be changed from nautical miles by modifying the coefficient (0.54) in the ground_degs calculation.

Figure 11.  Great Circle Route

Tier III: Refueling

The refueling model is a simple form where many complex distance calculations are being performed. The refueling model begins by flight planning the routes of the tankers using CFPS. Routes are imported and used in calculating amounts of fuel offloaded, crew duty day and the number and type of tankers to use. No GIS is used in the refueling model. All distances created by the aviation model are used to calculate fuel required by aircraft supporting ground missions.

 
Tier IV : C4I

The C4I database defines the architecture of the elements, tasking and information flow required to support the command’s missions. The JMA database includes command and control nodes requirements for each CONOP. When invoked by the C2 button, these nodes are used by the C2 Nodal Analysis Model to link the data between the nodes. For Special Forces units, this node capture process was generated by an automated model, which generated node requirements for analysis. The results are then linked using the same tools as any other unit. There are currently no GIS components used in the C4I models.
 

Logistics

The Logistics model assists the subject matter expert (SME) in analyzing logistical requirements for all units entered into the Joint Mission Analysis database. The Logistics model currently does not use any GIS functions.
 

End Result:

The end result of entering and modeling CONOPs is a database representing a fully resourced force structure for each scenario. Analysts run extractions from the database using the automated tools, and produce analytical products for the purpose of evaluation, identification of anomalies and capability assessment.

Finally, these analytical results from the JMA process must be put into a format that facilitates program assessment. Common PC tools for the production of graphs, charts, slides and maps are used to collate the data into numerous presentations that guide the remainder of the SPP.
 
 

2. Stage Two – Leveling:

In the leveling stage, the peak resource requirements are minimized by shifting CONOP start times within their limits. A suite of non-GIS systems are used to complete this function.

3. Stage Three – Output:

1. Output Products:

Products created by storing data within the database are:

• Maps displaying mission locations
• Level of effort charts depicting resources required by date
• GANTT charts displaying missions over time
• Organizational charts displaying Command and control hierarchy
• Ad hoc reports

2. Post Processing Computer-Based Analysis Tools:

1. Primavera Project Planner (P3)

P3 provides time-based analysis of missions and platforms in the JMA database. It gives the analyst a method of error-checking data to avoid timing conflicts, and depicts mission requirements and resource shortfalls over time. In addition, time-based analysis allows the analyst to view the "big picture"; that is, the ability to view all events occurring during a particular scenario and the ability to see what happens when changes are applied. An example of a Primavera report is shown in Figure 12.

Figure 12.  Primavera Sample Page

2. ArcView

ArcView is another module of SOFAMS. The ArcView spatial analysis extension provides a tool for immediately analyzing the missions entered into the JMA database. It can be used to depict unit locations, terrain features, buffer zones, targets, threats, and other items. A significant number of scripts have been written to accommodate the analyst in extracting data and displaying commonly requested data on the map. A set of scripts written to extract data from the SOFAMS database is shown in Figure 13.

Figure 13.  Arcview Scripts

Units can be extracted from the database and displayed by any unit characteristic the user wishes using the ArcView tool. The ArcView tool will display those units meeting the selected criteria in their respective locations as shown in Figure 14.

Figure 14.  Arcview Analysis Screen

3. Crystal Reports

Crystal reports is used for quick turnaround ad hoc reporting as shown in Figure 15. Database integration is easy to accomplish and summary to detail drill down is easy.

Figure 15.  Crystal Reports Example

Future Plans: 

The database needs to be accessible by other special operations components. Web enabling the JMA database for use by others is necessary for information sharing.

Additionally, new Logistics and C4I Models are going to be written in the near future. There are definite advantages to incorporating GIS into these new models.
 
 

Conclusion:

The constraints we faced seemed guaranteed to lead to failure. Development and implementation time constraints were extremely short, with great potential for error. Users were entering data using the forms and models as the software was being tested. However, the project was completed successfully and on time. The data entry and the analysis were also on time. The team kept good communications among themselves and (equally importantly) with the users. The users all work for the same supervisor and he carefully avoided all unnecessary requirements creep, while making clear what was necessary. We reviewed our status every week to avoid surprises. Contractor staff worked through the database structure in detail with each affected party of the government to assure not only its efficiency, but also its correctness to represent the missions and its amenability to the required analysis. The SOFAMS suite of tools represents an 80% time savings over previous database build methods.