**Real Time Mission Monitor (RTMM)**

**during the**

**NASA African Monsoon Multidisciplinary Analyses (NAMMA) Campaign**

**1. RTMM Background and Overview for NAMMA**

The Real Time Mission Monitor (RTMM) being fielded for the NASA African
Monsoon Multidisciplinary Analyses (NAMMA) campaign (August, September
2006) is a Google-Earth based situational awareness display that
integrates vehicle, instrument, and weather state information for NAMMA
participants. The integration and delivery of this information is made
possible through data acquisition systems, network communication links
and network server resources built and managed by collaborators at NASA
Dryden Flight Research Center (DFRC) and NASA Marshall Space Flight
Center (MSFC). In addition to the Google Earth Display, there are text
and voice communication services to and from the DC-8.

The NAMMA RTMM integrates satellite and radar imagery, model output
data, lightning location observations, aircraft (including balloon)
navigation data, overlays (e.g., dropsonde analyses), and other data
sets. A key addition and advance during NAMMA will be to provide, for
the first time, a local RTMM capability on the DC-8 aircraft itself
during the flights, enabling on-board scientists and aircraft operators
to have access to imagery and data sets unavailable in prior campaigns.

These services are evolutionary steps toward a general set of "sensor
web" and "intelligent airborne observation system" capabilities targeted
by Earth science technology insertion investments. These evolutionary
steps have roots dating back for at least a decade at both MSFC and
DFRC. The REVEAL (Research Environment for Vehicle-Embedded Analysis on
Linux) system prototypes of airborne sensor web infrastructure first
flew in November 2004. The first web display prototypes that used REVEAL
emerged in mid-2005, first for the Altair NOAA demonstration and then
during the Tropical Cloud Systems and Processes (TCSP) campaign. The use
of Google Earth and its constituent KML language as an integration
interface for real time displays was first applied during the NOAA
Demonstration (Altair) in the fall of 2005, and further refined during
the Intercontinental Chemical Transport Experiment (INTEX-B). The
current Google Earth-based RTMM also builds upon the solid heritage of
earlier mission (and weather) monitor applications implemented during
the Altus Cumulus Electrification Study (ACES, 2002) and other airborne
and ground-based missions.

Emerging from these iterative improvements is the capability to leverage
a single, easy to use graphical tool that supports science and logistics
decision-making by merging disparate and geographically distributed
information that is constantly changing. Behind the scenes, we are
designing a sustainable infrastructure able to grow and support
virtually any airborne science campaign, anywhere, anytime. Refinements
to the RTMM application presently underway (e.g., data playback) will
enable this tool to also support post-mission analysis.

Optimized decision-making derived from timely situational awareness is
only the immediate benefit. In the years to come the capabilities we
field here will continue to evolve toward increasingly more flexible and
dynamic combinations of sensors, network computing, and decision-making
activities. *We will evolve these capabilities into suborbital sensor
webs that help maximize the value of every flight hour spend conducting
airborne science*.

**2. Technical Description/Specifications**

# 

# RTMM Description

As previously noted, the NAMMA RTMM will be a web-based Google Earth
application. The basic components of the RTMM include the Google Earth
client display, and one or more "KML" files that tell Google Earth where
to pull information from, and how often to pull it. These data are
created and placed by the RTMM team on servers accessible by the NAMMA
participants. The Google Earth application combines satellite, radar,
model, and map ground overlay imagery that is correctly located on the
earth model. It also allows for screen overlays containing ancillary
imagery or text. Figure 1 is a screen capture of the Google Earth
display in the NAMMA domain.

The RTMM data are provided by a standard WEB server (Apache) to the
client\'s Google Earth display using http protocol. A large number of
software packages run on the RTMM servers to provide these data. These
packages ingest raw satellite, lightning, radar, navigation, and
dropsonde data. These data are converted to a form that is compatible
with the Google Earth display software. Model and other imagery are
created by other data providers and are downloaded to the RTMM server
for access by the Google Earth client. The RTMM servers also provide KML
scripts, (static and dynamic). These scripts may control the view that
is presented by Google Earth display or may be vector graphic draw
commands.

After initiating the Google Earth client, the user can exercise full
control over the display view and the data sets selected. The RTMM will
also provide an exciting new data playback capability. The user may
select the time frame and playback speed. The user may dynamically
change speed, pause, resume, or interrupt the playback sequence briefly
to view real-time data and then continue the sequence later in the RTMM
session.

# Network Design and Operation

The infrastructure that underlies and supports the NAMMA RTMM is a
distributed web-based network. Architecturally it possesses some key
elements of a Sensor Web, although data access and delivery represent
the primary function of the RTMM rather than truly interactive
communications amongst the instruments and computing elements. It is
also a complex global network containing ground-based and airborne
servers and distributed data sources accessed by a variety of
technological approaches including global broadband internet
connections, dial up modems to remote terrestrial sites, and satellite
phone links to airborne platforms.

The RTMM imagery and other data sets will be served using standard
apache web servers. There will be three such servers directly supporting
the RTMM during NAMMA. The "primary" server ("morna," full URL to be
provided later) will be situated at the Operations Center at the Sal
International Airport in Cape Verde. A "backup" server ("branch," full
URL to be provided later) will be located at the National Space Science
and Technology Center (NSSTC) in Huntsville, Alabama to provide
redundancy to the Cape Verde server. A third server will be located on
the DC-8 aircraft to provide RTMM support to scientists and crew on
board the aircraft during NAMMA flights. These three systems will be
configured identical to each other with respect to RTMM support. The
imagery and data available on the DC-8 server may be partially limited
and at a slightly lower resolution to accommodate the small REVEAL
(N-Channel gateway) up-link bandwidth capacity. However, there are plans
to maintain full resolution within 200-300 km of the DC-8 aircraft.

Figure 2 is a schematic diagram that depicts the NAMMA RTMM data flow
topology and the location of key servers, subsystems, and users that
supply, process, or receive RTMM data. Redundancy is built into the
network in a number of places to create a highly reliable and fault
tolerant system. The robust nature of this approach was aptly and
successfully demonstrated during TCSP, which employed similar network
architecture approach.

# RTMM Data Sets 

This section lists data products that will be included in RTMM during
NAMMA. Additional data or products may be added during the campaign. In
the RTMM Google Earth application, the user can select the data to be
viewed and control the display (region of interest, zoom level, etc.).

***Satellite***

GOES12

> \*VIS, IR4

Meteosat

> \*Bands 1,2,3,4,8,9,10

AMSRE-E

> \*Sea-Surface Temperature (when available)

TRMM

> \*3-hr global rainfall product (when available)

Satellite Track Prediction (To be implemented)

***Surface Observing System***

Radar

> \*TOGA, NPOL

Lightning

\*ZEUS, UK Met Office long-range lightning data

## **Airborne Observing System**

DC-8 (and other aircraft when available)

> \*Flight track (x, y, z, t), other state parameters

Dropsonde, Driftsonde

\*Navigation, observations

## **Model Analyses and Forecast Products**

MAP06 GEOS5 fields (0.25deg resolution, 1run/day):

\* Precipitation

\* Sea-Level Pressure

\* Surface Pressure

\* Wind Velocity

\* Surface Wind Velocity

\* Wind Shear (200mb - 850mb)

\* Divergence

\* Vorticity

\* Vertical Pressure Velocity

\* Surface Temperature

\* Temperature

\* Humidity

\* Geopotential Height

\* Storm Tracks

GMAO GEOS4 aerosol fields (1deg resolution, 2runs/day):

\* Total Aerosol Optical Thickness

\* Dust Aerosol Optical Thickness

\* Carbon Monoxide - Global

# Google Earth Client Software

Google Earth is available for Microsoft Windows, Apple, and Linux
operating systems. Google Earth may be downloaded from the URL:
<http://earth.google.com/>. It is the responsibility of each user to
download, install, and verify the operation of the Google Earth software
package on his/her machine. It is recommended that each user read the
relevant documentation located at the Google Earth home site.

#  Dropsonde Data

Although the dropsonde system and its in-flight operation is not part of
the RTMM per se, the near real time transfer of this data from the
aircraft to the ground and its subsequent ingest into the NOAA GTS
system is being addressed by the joint REVEAL/RTMM team. During
missions, dropsonde data (TEMP Message file and, probably a zipped full
drop data file) will be acquired (after splashdown) from the dropsonde
system by the N-Channel system. This data will be then sent to the
Global Range server where it will be ftp'ed to a MSFC server for
transmittal to GTS and the NAMMA servers. Software on the ground-based
servers will regenerate sounding plots (i.e., skew-Ts) for web access by
scientists. The dropsonde system on board the DC-8 also generates the
sounding plots. These plots will be available to the scientists onboard
the DC-8 via its LAN.

**3. Roles and Responsibilities**

  ----------------- -------------------- --------------------------------
  **Name**          **Institution**      **Role**

  Richard Blakeslee NASA MSFC / NSSTC    PI for RTMM

  John Hall         SAIC/NSSTC           RTMM Software Developer /
                                         Analyst

  Michael Goodman   NASA MSFC / NSSTC    PI for Data Management

  Phil Parker       UAH / NSSTC          Data Management -- Sys Admin and
                                         RTMM Software Support

  Danny Hardin      UAH / NSSTC          Data Management -- Web

  Kira Gee          UAH / NSSTC          Data Management -- Web

  Lynne Carver      UAH / NSSTC          Data Management -- Web

  Marilyn Drewry    UAH / NSSTC          Data Management -- Database

  Larry Freudinger  NASA DFRC            PI for REVEAL

  Carl Sorenson     NASA DFRC            REVEAL Support

  Sky Yarborough    NASA DFRC            REVEAL Support

  Brent Bieber      NASA DFRC            REVEAL Support
  ----------------- -------------------- --------------------------------

**4. Tasks and Schedule**

# RTMM Pre-mission Development

During a few months leading up to the NAMMA mission, a RTMM Google Earth
application tailored to NAMMA has been developed and refined. During
this period, the key data sets have been identified, acquired, and
implemented. Feedback on these data and the RTMM functionality has been
solicited. This process will continue up to and including during the
mission itself. Also, during the pre-mission phase the network
connectivity and architecture was developed and tested, and support
hardware (primarily servers) were procured and/or set up. Testing will
continue on the RTMM functionality and networking.

# DC-8 Integration and Test Flights

During a July, a RTMM Google Earth application was installed and
successfully tested on the DC-8 aircraft, including some end-to-end
tests through REVEAL and the N-Channel system to the ground-based
servers. These tests will continue though the scheduled test flights.
Some network issues identified during the initial integration tests
continue to be worked.

# Mission Operations

During NAMMA campaign, RTMM and REVEAL personnel will closely monitor
the activities of the RTMM, REVEAL and dropsonde data transfer
operations. For the RTMM, there will be two support personnel at Cape
Verde. An RTMM support person will fly on the DC-8. During the initial
period of the campaign, John Hall, the lead RTMM software developer will
be in the field at Cape Verde to address issues that might arise. Philip
Parker will remain at Cape Verde throughout the campaign to provide
local support should it be required. Since the RTMM is a distributed
web-based system, John Hall will continue monitor and support the RTMM
system once he returns to the United States.

**5. Field Support Requirements**

The field support requirements for the RTMM portion are modest. The
"primary" server "morna," will be located at the Operations Center at
the Sal International Airport in Cape Verde. Access to power and the
Internet are required. Static (i.e., fixed) IP addresses are required (5
desirable) to support the RTMM network. These IP addresses need to be
conveyed by phone or fax to the RTMM team as soon as they are known to
minimize any adverse impact to the mission caused by blocking of the
network connections when approved IP addresses are not in place. From a
facilities standpoint, table space and chairs are requested to support
up to three RTMM team members and their associated computers, printer,
and office/computer supplies.

**6. Success Criteria**

As noted in the introduction, this effort represents an evolutionary
step toward a general set of "sensor web" and "intelligent airborne
observation system" capabilities targeted by Earth science technology
insertion investments.

A key objective during NAMMA will be to provide, for the first time, a
local RTMM capability on the DC-8 aircraft itself during the flights,
enabling on-board scientists and aircraft operators to have access to
imagery and data sets unavailable in prior campaigns. We our desire is
to provide a new level of situational awareness onboard the aircraft
similar to what is available on the ground that can be used in mission
decision support and execution. Measures of success for the RTMM on the
DC-8 will include how well we are able to accomplish this objective and
how (and whether) the RTMM is used to support mission operations. This
later point (how it is used) will depend critically on getting the data
to the aircraft in a timely manner. We would like to accomplish our
aircraft RTMM objective without impacted the XChat capabilities that
have already been successfully demonstrated. The RTMM and REVEAL teams
will monitor this closely and solicit feedback during and after the
mission to continue to improve upon the services and capabilities
provided.

The RTMM will also support mission planning, mission
execution/coordination and post-mission analysis at the NAMMA operations
center and other ground-based locations. In this case, it will also
include bringing data down from the DC-8 aircraft, including the
aircraft navigation and dropsonde data. Again the primary success
criteria on achieving this objective will be directly related to how
much the RTMM is used.