Combat fire support and situational awareness? There's a smartphone app for that

Story

September 02, 2011

Could it actually heighten situational awareness to help save warfighter lives or even provide aid in combat fire scenarios? The answer is a resounding yes, and a Composable Handheld Android Platform (CHAP) comprising a Call For Fire (CFF) Mission Thread is key. (U.S. Army photo by Heather Vann)

Despite technological advances across the board, the Department of Defense continues to grapple with a familiar capability gap – situational awareness, particularly the availability to deploy small, dispersed, mobile units. While situational awareness tools are now heavily automated, the route that many DoD technologies are taking, this automation emerged in the matrix of legacy command and control architecture with thick clients, voice communications, authoritative data sources, and centralized command centers. However, doctrine and operational practice have now outgrown such an architecture. Small, highly mobile, increasingly autonomous units (and even individuals) are intended to operate in a net-centric fashion, but legacy issues of network infrastructure, heavy systems, and lack of access to data continue to limit mobile situational awareness.

Combat fire support poses a particularly tough challenge for mobile units. Its stringent requirements for timeliness and accuracy and inherent lethality as well as dependence on an accurate operational picture suggest that if a system works well and reliably for fire support, it should also lend itself to other domains. Such a mobile combat fire support system now exists for military use, the Composable Handheld Android Platform (CHAP), which comprises a Call For Fire (CFF) Mission Thread, Infrastructure as a Service (IaaS), Software as a Service (SaaS), a Web portal, and an Android or iPhone smartphone application and associated services. The following discussion examines the different components that enable a CFF to be executed from the CHAP, from functionality of the device to the makeup of the systems behind CHAP.

Eyes on situational awareness

Complete situational awareness comes from eyes on a target (for example, video feeds from UASs), Blue Force and Red Force locations and descriptions, current and accurate imagery/maps, and local area intelligence. With the aforementioned technology unified into a single system, CHAP provides an observer with necessary intelligence, as well as the ability to modify, delete, or create tracks (actual moving targets) directly from the mobile device. Fire support can now be called in through a Droid or iPhone application, simply by confirming the target via the touch-screen; this smartphone-based support also gives the warfighter access to other intelligence via data services functionality, including chatting with other units currently connected to CHAP in the cloud. A screenshot of the soldier’s view can be seen in Figure 1.

 

Figure 1: Droid soldier view – Call For Fire (CFF) Android application

(Click graphic to zoom by 1.9x)

 

When a target is created, it is reported through the cloud, processed through a Complex Event Processing (CEP) engine, and sent to the secure commander portal in real time for review and authorization. Via the portal, the operation commander can view an entire Common Operational Picture (COP), which runs as SaaS within the IaaS. Additionally, any authorized users in the portal can create a customized view, or User Defined Operational Picture (UDOP). The user can select from a library of widgets (such as Google Earth and NASA World Wind) to build their UDOP, which can be seen in the screenshot of the Commander’s view (Figure 2).

 

Figure 2: Commander portal view

(Click graphic to zoom by 1.9x)

 

The prime question remains, however: What does each disparate piece of technology bring to the table, ultimately enabling mobile situational awareness for the warfighter? We’ll start by examining the CFF Mission Thread.

Live fire – CFF Mission Thread

The CFF Mission Thread is a series of documented processes, involving dozens of parallel systems and applications as well as high command review built around an observer (for example, a warfighter) using a smartphone to call for fire. This is done simply by the user holding his/her finger on the target for a few milliseconds until the command is transmitted to the cloud for analysis, against a target, whether an enemy vehicle, strongpoint, building, or unit. The Mission Thread is the backbone of CHAP, allowing the warfighter to call for, and receive, fire support in a hostile situation. For the Mission Thread to function as needed, however, several criteria must be met.

First and foremost, the observer must be connected to the military network and the supporting applications, like the Address Book, must be online and functional. Next, the operation commander’s criteria and Fire Support Coordinating Measures (FSCMs) must be readily established guidelines for the type of fire support to be received: how this incoming fire will affect nearby operations and whether or not air support is to be received. Finally, the observer must have a laser (used to “paint” the target/targets), and there must be weapons positioned in the area of operations to actually fire on the target.

When these criteria are met, fire support can be received. As for the type of fire support, Precision Guided Munitions (PGMs) must be employed, which provide near-pinpoint accuracy to the observed target. In this case, PGMs can include supporting fire from howitzers, tanks, unmanned aerial systems (like the Predator drone), and attack helicopters.

To prevent unauthorized use or interception, the Droid or iPhone used by the observer could be equipped with a Type I Encryption Sleeve. Currently undergoing prototype testing with NSA, this is similar to a standard smartphone case or iPhone “powerpack” that locks around the outside of the smartphone, providing Type I encryption capabilities to a typically unsecured device.

Fire from the cloud

CHAP relies heavily on the cloud for its flexibility and overall functionality to the warfighter, primarily via IaaS and SaaS. IaaS renders the virtual environment transparent to the end user, allowing updates to the applications (such as the Droid app, services, business rules engine, portal, and widgets) and the underlying infrastructure to occur without procuring physical memory, storage, or processing power. Meanwhile, SaaS enables easy deployment of COTS soft-ware for additional functionality within the technology. Enterprise services provide a foundation for interoperability among the capabilities deployed within the cloud environment and consist of eight separate services:

1. Discovery Service

2. Messaging Service supporting AMQP and Java Message Service (JMS)

3. Orchestration Service

4. Real-time Collaboration Service

5. User-facing Services

6. Security Services

7. Mediation Services

8. Enterprise Service Management (ESM)

Along with the aforementioned enterprise services, the Department of Defense’s Universal CORE (UCore) data model is also used, allowing the simulated data services running in the cloud to talk to each other. Additionally, UCore in this application is extended to support Track Metadata, Video MetaData, and Variable Message Framework (VMF) messages for position location, along with Keyhole Markup Language to support Google Earth Integration.

The simulated data services include multiple intelligence systems, including sensor data from remote monitoring units, video feeds from UASs and aircraft, maps, and other imagery. Most notably, the Global Command and Control System-Joint (GCCS-J), a DoD legacy system, is also run in the cloud as a simulated data source. To do this, a tracks service (an application/messaging service to transmit tracks/target information) was written on top of GCCS-J, allowing it to push its data into the cloud for use by the other cloud-based services.

For the final step in the cloud, a Universal Description Discovery and Integration (UDDI) registry stores all the services and their associated data models for CHAP, which allows the disparate systems making up CHAP to find the appropriate service when needed for a specific event, like an acquired target or a request for fire support. A CEP engine then processes these multiple events and messages to determine which should be acted upon, in conjunction with a Business Rule Management System (BRMS) that defines, deploys, and executes business rules for the system.

As an example, the CEP engine has a rule to easily let commanders see when a tank or other mobile firing platform is running low on ammo. More specifically, when a tank’s ammo threshold drops below 20, the affected tank turns blue, allowing commanders to easily see which tanks are friendly (blue), hostile (red), or low on ammo/resources (green). The Commander Portal contains a widget to view this on the Map for SA.

Forging ahead under fire

This technology was co-developed by QinetiQ North America and Red Hat in their internal research and development program. The current technology source code is available via projects within the DoD’s Forge.mil, including an Android project established during this technology’s development. The system described herein was developed to demonstrate the art of the possible for the current tactical and enterprise environment. The technology is being refined for deployment to warfighters who need near-real-time situational awareness – and that, of course, is every warfighter whose boots are on the ground.

Michael Howard is the Vice President of Advanced Enterprise System Solutions for QinetiQ North America’s Systems Engineering Group. He has been recognized throughout the DoD for his efforts in Service Oriented Architectures (SOAs), Master Data Management (MDM), System of Systems (SoS) Engineering, and SoS integration. He holds a BS in Computer Engineering from the University of South Carolina. Email: [email protected].

QinetiQ North America 843-740-7456 www.qinetiq-na.com