2 CSUS I-Scan Group California State University, Sacramento Skylar BemusSamuel JohnsonDan MarconettRyan JarvinenDan PotterProject SponsorLarry FreudingerNASA Dryden Flight Research CenterAdvanced Test Technologies Lead
3 NASA Dryden Airborne Sciences Directorate Advanced Test Technologies GroupDeveloping Over-the-Horizon network capability for long endurance test flightsUse airborne platforms for sensor web deployment
4 Industry Collaborators Creare Inc.Hanover, New HampshireInternational research and development firm, creators of RBNB technologyProvided advise and expertise with respect to leveraging RBNB technology as well as consultation about the various design aspects of the projectResponsible for developing mechanism to introduce time-sensitive data to the Google Earth applicationAero InstitutePalmdale, CaliforniaPartnership of individuals, Federal, State and Regional governments, commercial companies, academic institutions; and non-profit organizationsMain purpose to facilitate applied research projects and educationProvided I-Scan project funding
5 Technology GapsThere exists a need for network-computing solutions for airborne sensor web applications which address:Time oriented monitoring of the observation fieldTivo-like ability to scroll back and forth through sensor data, both image and scalarUnifying 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 regionsOne facet is using UAV’s to monitor Emperor Penguin colonies, as they are an indicator species of regional climate in AntarcticaAbility 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 webUsing Creare’s Ring Buffered Network Bus (RBNB) as a data staging mechanism at each layerJava VM compliant to ensure portabilityLeverages Google Earth as a “killer app” to fuse image and other sensor dataGeneral 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 platformEach location running local monitoring appCentral data staging area, accessible via the internetCentral server running kml creator plug-in to create a unified kml for all locationsMultiple end-users acquiring data in real-time
10 XML ConfigurationThe local monitor app monitors sensors which are defined by the xml configuration fileLocal paths to data are specifiedSubset 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 MetadataData which adds understanding to the image data can be classified as metadataGPS 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 GenerationKeyhole 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.
14 Testing IssuesMulti-tiered architecture provided component communication challengesDeviations 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 websGoogle 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-timeMetadata relationship needs to be further investigated, one person’s metadata is another person’s primary data