CSUS I-Scan Group California State University, Sacramento

2. CSUS I-Scan GroupCalifornia 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