2. CSUS I-Scan Group California State University, Sacramento
Skylar Bemus
Samuel Johnson
Dan Marconett
Ryan Jarvinen
Dan Potter
Project Sponsor
Larry Freudinger
NASA Dryden Flight Research Center
Advanced Test Technologies Lead

3. 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

4. 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 Institute
Palmdale, 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

5. 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

6. 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

7. Computational Solution
Generic 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

8. 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

9. System Workflow

10. 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>

11. 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

12. 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.

13. Google Earth

14. 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.

15. 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