CSUS I-Scan Group California State University, Sacramento Skylar Bemus Samuel Johnson Dan Marconett Ryan Jarvinen Dan Potter Project Sponsor Larry Freudinger.

CSUS I-Scan GroupCalifornia State University, Sacramento

Skylar BemusSamuel JohnsonDan MarconettRyan Jarvinen

Dan Potter

Project Sponsor

Larry FreudingerNASA Dryden Flight Research Center

Advanced Test Technologies Lead

NASA Dryden Airborne Sciences Directorate

Advanced Test Technologies Group• Developing Over-the-Horizon network capability for long endurance test flights• Use airborne platforms for sensor web deployment

Industry Collaborators

Creare Inc.Hanover, New Hampshire• International research and development firm, creators of RBNB technology• Provided advise and expertise with respect to leveraging RBNB technology

as well as consultation about the various design aspects of the project • Responsible for developing mechanism to introduce time-sensitive data to

the Google Earth application

Aero InstitutePalmdale, California• Partnership of individuals, Federal, State and Regional governments,

commercial companies, academic institutions; and non-profit organizations• Main purpose to facilitate applied research projects and education• Provided I-Scan project funding

Technology Gaps

There exists a need for network-computing solutions for airborne sensor web applications which address:

• Time oriented monitoring of the observation field

• Tivo-like ability to scroll back and forth through sensor data, both image and scalar

• Unifying application to tie sensor data acquisition with geo-spatial observation/orientation

Scientific Impetus

International Polar Year 2007-2008• Multinational Earth Science community’s effort to study the Earth’s

polar regions• One facet is using UAV’s to monitor Emperor Penguin colonies, as

they are an indicator species of regional climate in Antarctica• Ability to scroll back and forth through time with data has been

identified as a desirable capability for this mission

Computational SolutionGeneric application layer

distributed sensor web • Using Creare’s Ring

Buffered Network Bus (RBNB) as a data staging mechanism at each layer

• Java VM compliant to ensure portability

• Leverages Google Earth as a “killer app” to fuse image and other sensor data

• General solution to a problem of monitoring multiple geographically distributed sensor webs, regardless if location is static, or onboard an airborne platform

Testbed Architecture

Three-tiered network-distributed architecture

• Multiple data acquisition locations, each simulate an airborne or fixed monitoring platform

– Each location running local monitoring app

• Central data staging area, accessible via the internet

– Central server running kml creator plug-in to create a unified kml for all locations

• Multiple end-users acquiring data in real-time

System Workflow

XML Configuration

The local monitor app monitors sensors which are defined by the xml configuration file

• Local paths to data are specified• Subset of sensors defined as metadata

<collection name="" static=”” destURLPath=“”>

<sensor kml=""> <monitor destName="" minimumInterval="" mkcolQuery="">

           <url> </url>         </monitor>         <metadata>

<metasource balloon=””>               <tag> </tag>                  <channel> </channel>

</metasource>

</metadata>

</sensor>

</collection>

Metadata

Data which adds understanding to the image data can be classified as metadata

• GPS coordinates, wind speed, temperature, etc (other sensors)

• Metadata can be tied to different image sensors depending on the relationship defined at the local configuration level

KML Generation

Keyhole Markup Language (KML) files are used by Google Earth to define data such as image overlay positioning, geographic points, lines, etc.

• Local monitor application generates a single KML template which corresponds to the sensors defined in the XML configuration file.

• This template is then given its own RBNB data channel and sent to the central server.

• The central server services new KML requests by querying the data channels which correspond to the data fields in the kml template, based on what the desired time of the data is.

• Central server app then combines the several local monitor templates into a single master KML file which is then returned to the Google Earth app.

• End-user is able to view latest data from all monitoring locations which pertains to the time requested, most recent data being the default request.

Google Earth

Testing Issues

Multi-tiered architecture provided component communication challenges

• Deviations from predefined interaction, i.e. a component misstep, created instability in the network testbed.

• Major concern of distributed systems, time synchronization between end systems, created challenges since data is acquired and tagged based on local machine time.

Concluding Commentary

This project has been a baseline validation of a network centric hypothesis for a computing solution to geographically distributed imaging sensor webs

• Google Earth or an application like it will be needed for basic observation application which supplies scientists and engineers with the needed information all in one place, in near real-time

• Metadata relationship needs to be further investigated, one person’s metadata is another person’s primary data