# Presentation: 640680

## An EOS Brown-Bag Lunch Presentation

Stephen J. Talabac
NASA/GSFC Code 586
April 11, 2003

- Stephen J. Talabac
- NASA/GSFC Code 586
- April 11, 2003

- Sensor Webs*An Emerging Concept for Future Earth Observing Systems*

## Agenda

- Background, terminology, and fundamental concepts
- A candidate sensor web definition
- Taxonomy and properties of sensor web nodes
- Possible sensor web classes and their properties
- Representative scenarios that may benefit from the sensor web concept
- A survey of related research activities

## Background

- NASA’s and the Earth-Science Enterprise’s strategic plans identify “sensor webs” as a new paradigm for conducting future science observations.
*“**We envision multiple cooperative spacecraft that operate in interactive networks to thoroughly explore diverse phenomena”*
*“...**intelligence will become an integral part of future spacecraft, enabling systems to make real-time decisions in the uncertain and unforgiving space environment”.*
*“**Deploy cooperative satellite constellations and intelligent sensor webs.” that will facilitate“information synthesis” and increase our “access to knowledge”*

*“**The best way to be ready for the future is to invent it.”*John Sculley – CEO, Apple Computer

## Background (continued)

- The Sensor Web concept is being refined and various views of it appear to be converging.
- We are presently exploring questions such as:
- What exactly “is” a sensor web?
- What are the specific characteristics that a sensor web should possess?
- What are the various behaviors that a sensor web may manifest?
- ...and most significantly: What are potential applications of sensor webs that can be of significant benefit to the Earth science community?

## Sensor Webs:A Systems Engineering Approach

- Establish a common terminology vocabulary
- Identify sensor web nodes, define their properties, and develop a node taxonomy
- Describe how nodes might interact and used as building blocks to develop a taxonomy of sensor web classes
- Identify science scenarios that may benefit from the various sensor web classes
- Identify candidate sensor web architectures and establish evaluation criteria

## Space Mission Architecture - Today

**Science Processing Center**** **

**Science Processing Center**** **

- Graphic Credit: NASA/GSFC *2000 Survey of Distributed Spacecraft Technologies and Architectures for NASA’s Earth Science Enterprise in the 2010-2025 Timeframe*

- Bent pipe communications

- Direct instrument readout
- or
- On-board recorder downlink to Ground Station

## Space Mission Architecture - Today

- Classic “stovepipe1” science data collection and mission operations
- Single or separate spacecraft missions with little or no dynamic planning for opportunistic science observations or handling unexpected observing conditions
- Data is often simply recorded and downlinked to ground systems for processing and analysis
- “Fire hose” of raw data bits downlinked to the ground with little or no regard to sending just the most meaningful science data
- Little, if any, on-board science instrument processing
- No real time collaborative information sharing between sensors, spacecraft, or investigators
- Interspacecraft communications typically relegated to bent pipe communications to the ground segment
- e.g., via TDRSS in support of command uplinks, telemetry downlinks
- 1 *stovepipe* - a self-standing, narrowly focused application that solves a discrete set of problems

## Space Mission Architecture – “Tomorrow”Distributed Spacecraft Systems & Sensor Webs

## Space Mission Architecture - “Tomorrow”

- High degree of synergy between a diverse suite of platforms
- Space-based
- Atmospheric (e.g., aircraft, balloons)
- Land (e.g., in-situ weather stations) and sea (e.g., buoys)
- Subsurface probes
- Automated science data collection and mission operations
- Multiple spacecraft and platforms perform dynamic planning for opportunistic science observations
- Real time collaborative information sharing between sensors, spacecraft, or investigators
- Interspacecraft communications becomes an intrinsic characteristic of distributed space platforms

## Emerging & Evolving Technologies

- Micro-electromechanical Systems (MEMS)
- Nanospacecraft
- Low mass, small footprint in-situ sensors
- Advanced processors & high capacity storage provide
- Greater opportunity for on-board processing
- Embedded software to build “intelligent” processing nodes
- Communications
- Evolving space-based IP comms protocols and interoperability with terrestrial networks
- Ubiquitous wireless comms allows for “ad hoc” Sensor Web networks to be established
- Peer-to-peer networking

- MEMS Microthruster Array - 10-4 Ns Impulse
- Photo : TRW

- NASA NMP - ST5 spacecraft

## Terminology1 - Sensor

- A device that measures a physical property of a natural or man-made phenomena that is of interest to Earth- and space-scientists
- A sensor is an integral part of, and provides its measurements to, a *science instrument*.
- Examples
- A prism and CCD sensor array that captures and measures photons of different energies (i.e., wavelengths) and intensities (i.e., photons per second)
- A water flow rate sensor
- Two types of sensor measurements
**in-situ **(e.g., magnetic field strength)
**remotely sensed **(infrared energy reflected from clouds at different heights)
- Measurements are not necessarily restricted to photons
- Rainfall amount
- Acoustic energy
- Chemistry
- 1D/2D/3D/6DOF directional measurements
*Note 1: These are not meant to be strict definitions. Instead they are intended to provide an “informal” definition of fundamental concepts, often expressed in terms of other widely accepted and commonly understood terminology.*

## Terminology - Science Instrument

- A self-contained infrastructure that
- Receives (digital or analog) data from one or more sensors
- Provides temporary storage for the measurements
- Transmits sensor data to a *node*
- It* may* have its own infrastructure to sustain its own operation (e.g., power, structure, environmental, etc), or it may rely entirely on the *node* (e.g., a spacecraft bus) for this infrastructure
- Examples
- rain gauge
- magnetometer
- IR observatory
- laser interferometer

## Terminology - Node

- A self-contained computing, storage, and communications device.
- A node *may*, but not necessarily, be connected to one or more *science instruments*.
- A node provides mechanical, power, thermal, electrical, communications, control, timing, environmental protection, etc. to support its own operation and possibly for any science instrument directly connected to the node.
- A *node* may be a spacecraft that has one or more science instruments
- A *node* may be a computing or storage system that does not have any associated science instrument(s)
- Example of nodes:
- A spacecraft bus that supports one or more science instruments
- A ground-based radio telescope observatory
- A computer that executes a model (e.g., numerical weather prediction; algal bloom formation, growth, and dispersion)
- A geolocated database that stores historical information (e.g., seasonal hurricane formation locations; seasonal algal bloom population emergence locations)

## Node Types

## Node Concept & ConnectivityAnother view...

- Communications
- Fabric

- This node does not have
- a Science Instrument/Sensors

- Node Platform

- Science Instrument
- &
- Sensors

- Sensor 1

- Node Platform

- Optional Instrument with Sensors

- Optional Instrument with Sensors

- Sensor 2

- Sensor m

- Sensor 1

- Sensor 2

- Sensor n

- Mechanical

- Power

- Thermal

- Node Control

- Instrument
- Data
- Processor

- Instrument
- Data
- Storage

- Comms
- Fabric
- I/F

## Terminology - Data

- Loosely defined to mean *any “string of bits”*.
- Data bits may represent
- Raw sensor or science instrument data
- Processed science data
- Ancillary information required to perform science data processing
- Node or instrument state data (e.g., spacecraft health and safety engineering telemetry data; instrument mode of operation; ...)
- Commands to the node and/or science instrument to change its operating state
- Executable code (i.e., algorithms) to be executed by the node
- Sensor web system state messages

## Terminology - Communications Fabric

- A communications infrastructure that permits nodes to transmit and receive data between one another
- The scope of the communications fabric encompasses
- The communications media (e.g., wired vs. wireless; optical vs. RF; baseband signal vs. modulated; etc)
- The communication topology (e.g., ring, star, mesh, etc)
- Communications fabric protocols

## So...what “is” a sensor web?

- As is often the case with emerging concepts, there is presently no single, widely accepted definition.
- A candidate definition:
*A Sensor Web is a distributed system of sensing nodes that are interconnected by a communications fabric and that functions as a single, highly coordinated, virtual instrument. It autonomously detects and dynamically reacts to events, measurements, and other information from constituent sensing nodes and from external nodes (e.g., predictive models) by modifying its observing state so as to optimize science *_*information*_* return.”*

*“**Scientific progress consists in the development of new concepts.”*Ernst Mayr – renowned 20th century evolutionary biologist

**Notes:**
I have proposed this definition

## Sensor Web Conceptual Diagram

**Notes:**
- The communications fabric is not meant to imply just one “network”, nor does it imply any particular medium (RF, wired, fiber optics), nor specific connectivity such as a ring network versus a fully-connected mesh topology. It simply means that nodes use the communications fabric to send and receive data to/from one another.
- Some nodes are shown having science instruments whereas others do not have instruments. An example of a node with no instruments is a computer system that executes a numerical meteorological forecast model and that provides its results to one or more other nodes.

- Instrument Node

- Instrument Node

- Instrument Node

- Predictive Model Node
- (has no science instrument)

- Non-photon science instrument data
- (e.g., distance measurements from a laser rangefinder)

- Information Fusion/Synthesis Computing Node

- Communications
- Fabric

- Database Node

## Sensor Web Components:Autonomous Dynamic Interactions

***Communications***
***Fabric***

**Sensor**
**Nodes**

**Computing**
**Nodes**

**Data**
**Stores**

** *****In situ***** & remote sensing *****observations***
** ****Individual & collaborative *****event***** *****detection***** and phenomenon recognition**
** *****Notification***** of other nodes**
** *****Reaction***** & *****Response***** by nodes**
** ****Node *****reconfiguration***
** *****Temporal***** (e.g., measurement rate), *****spatial***** (e.g., new location, higher resolution, form new cluster), *****spectral***** (e.g., activate different band)**

**e.g., Predictive models,**
** ****information synthesis,**
**observational data assimilation**

**e.g., Historical Information**

## Why are Sensor Webs Important? “In the future, the research models of today will be the application models of tomorrow... What kind of observing system will we need?”Dr. Mark Schoeberl, GSFC Science Data Processing Workshop February 2002

- “Sensor-web enabled systems are uniquely capable of performing real-time analysis and decision making to autonomously execute complex adaptive observing strategies.” E. Torres-Martinez, M. Schoeberl, M. Kalb; June 2002 IGARSS
- Ability to “aggregate/synthesize science data by clustering, or some other local data aggregation methods, to generate global high-level interpretations” XEROX PARC CoSense Project

- Sensor webs will inextricably link in-situ & remotely sensed observations with model outputs and information repositories from geographically dispersed and disparate sources; not possible with stand-alone sensors.
- “Improve the performance of weather and climate predictive systems and extend useful range of forecasts.” Ibid E. Torres-Martinez et al

- Graphic Credit:
*Earth Science Vision 2002*
*Access to Knowledge*
- Dr. M. Schoeberl

**Notes:**
Mention that Ed and Mark’s paper for June 2002 IGARSS references my taxonomy definitions

## Why are Sensor Webs Important?“Ideas won't keep; something must be done about them.”Alfred North Whitehead

- Achieve science objectives unattainable using single nodes
- Phenomena that occupy a very large spatial domain - “Local data is too weak to form coherent global interpretation”
- Xerox PARC “CoSense” project
- Magnetosphere
- Multipoint, time synchronous observations
- Arrays of large effective aperture instruments

- Reduce system response time
- Monitor rapidly evolving, transient, or variable events/phenomena
- Conduct time constrained observations without *a priori *or* having incomplete* knowledge of conditions at observing time
- Conduct observations where communication times are too long for humans to make real- or near-real-time decisions
- Improve utilization of platform & instrument resources

***The phenomena we observe are intrinsically dynamic ... as must be the sensor web information systems that will enhance our ability to observe and better understand these phenomena.***

**Notes:**
Talk to top two bullets and bottom italics

## A Groundswell of Sensor Web Research

- Multi-Resolution Data Fusion
- Duke University - SensIT

- Sensor Web for In Situ Exploration
- of Gaseous Biosignatures

- Credit: NASA/JPL

- UAV Research
-  Berkeley SensIT

**Notes:**
Duke University: Multi-resolution and fault tolerant sensor fusion for hierarchically organized sensor networks. Design of information integration algorithms.
DARPA Dynamic Sensor Networks: USC, UCLA, VA Tech examining routing protocols and addressing for multicast, anycast, etc protocols as the node spatial domain changes. Using JAVA.
CoSense: Studying tactical awareness using spatio-temporally distributed signal streams. Data interpretation by blending modeling with statistical techniques.
JPL: In-site environmental monitoring and exploration. Focusing on very small deployable sensors.
BBN: Research into highly scalable routing protocols for up deployable 10,000 node networks
Berkeley: Tracking vehicles using UAV’s to deploy sensor nodes network from the air. Nodes establish multihop routing. UAV interrogates and gathers sensor data and routes to central command for analysis.

## Sensor Web ResearchNASA/JPL

- “A Sensor Web consists of intra-communicating, spatially-distributed sensor pods that are deployed to monitor and explore environments.”
- “It is capable of automated reasoning for it can perform intelligent autonomous operations in uncertain environments, respond to changing environmental conditions, and carry out automated diagnosis and recovery.” *Dr. Kevin Delin, JPL Sensor Web project leader*
-  The "hopped" data is shared by all of the pods, allowing each one to know what is being collected elsewhere on the web.”

- Images Credit: NASA/JPL

- A Sensor Web measuring biosignature gases to search for microorganisms living beneath the surface of a planet.

- JPL Sensor Web “Pod”

## Sensor Web ResearchDARPA Sensor Information Technology Program

- Xerox/PARC: *CoSense Project*
- Using sensor collaboration to make sense of aggregate phenomena that are not local in time and space
- Leader-follower formations
- Clustering of enemy forces
- Track multiple maneuvering targets, without a priori knowledge of paths
- A data association problem
- Estimate target position versus time
- How many nodes are required?
- What are the impacts of node spacing?
- How to perform distributed analysis with 100s and 1000s of nodes
- For very large numbers of nodes
- How to perform (and perhaps optimize) cluster maintenance and node reconfiguration to ensure efficient node collaboration?

- Perimeter violation sensing
- monitor only events within a predefined area; ignore all others.
- Target tracking and “reasoning”
- Detecting a particular target signature implies the existence of another target signature
- Information directed sensor querying
- Select next sensor to query to *maximize *information return while *minimizing *latency & bandwidth consumption
- How do you infer the properties of a global set of targets vs. individual target properties?

## Sensor Web ResearchDARPA Sensor Information Technology Program

- Sensoria Corporation
- Examining dynamic network assembly to build deterministic networks
- BAE and Sensoria
- Auto track a vehicle
- Create initial estimate of future velocity and location
- Coordinate all nodes to image the vehicle when it is in view

- Nodes share event detection info and tracking states
- Nodes contribute to improved initial tracking estimate
- Technologies
- Sensor signal processing
- Sensor signal/information fusion
- Seismic
- Acoustic
- Infrared
- Routing algorithm is insensitive to loss of nodes
- Image trigger estimators

## Sensor Web ResearchDARPA Sensor Information Technology Program

*MU-Fashion*
*Multi- Resolution Data Fusion using Agent- Bearing Sensors In Hierarchically-Organized Networks*
- Duke Univ, LSU, Univ. of TN
- Examining problems associated with:
- Sensor data fusion
- Multi-resolution, fault tolerant target detection & classification
- Sensor deployment algorithms to optimize target detection and minimize communications bandwidth
- Working with BBN on sensor power management
- for devices that operate in multiple power states
- Using RT-Linux

## Sensor Web ResearchDARPA Sensor Information Technology Program

- BBN
- Large-scale, distributed, intelligent sensor networks
- 10,000 nodes +
- Use peer-to-peer communications protocols
- Ad hoc mobile networks
- Scalable architecture
- supports numerous diverse and heterogeneous sensor types
- XML Messaging Standards
- allows sensors to communicate and share information
- XML messaging standards
- Java-based solution

## Sensor Web ResearchDARPA Sensor Information Technology Program

*Dynamic Sensor Networks* -  USC, UCLA, VA Tech
*Distributed Services for Self Organizing Sensor Networks* - Auburn University
- “Provide services that enable distributed sensor software components to self-organize, adapt to changing requirements, react to network changes, relocate and survive sensor failures in a dynamic ad hoc network”

*Distributed Cognition through Semantic Information Fusion: Penn State*
- Low bandwidth comms requires  abstraction of data
- Platforms self organize into local neighborhoods and share local data
- Collaborative signal processing

## NASA/GSFCAutonomous Nano Technology Swarm: ANTS

*An Artificial Intelligence Approach to Asteroid Belt Resource Exploration: **Dr. Steve Curtis*
- Scientifically categorize all asteroids > 1 km in diameter
*“**Mission goals are achieved through emergent, collective behavior”.*  Dr. Steve Curtis
- Very large numbers (“swarms”) of picospacecraft (~1kg) with wide variety of instruments
- X-ray
- Gamma ray
- Magnetometer
- IR/Vis/UV spectrometers
- Swarm heuristics planner and distributed intelligence operations

## Sensor Web Research at GSFC Sensor Web Application Prototype (SWAP)

- ESTO FY01 Funded Prototype Research
- Meteorological application in collaboration with Dr. Marshall Shepard
- Dynamic instrument collaboration for flash flood prediction
- Automated response and reconfiguration of simulated NWS Doppler radar array
- “Intelligent“ rain gauges automatically initiate a simulated Doppler radar mode change from “sweep“ to “sector scan“.

- weather
- simulator

- Embedded Processor

- Doppler Radar “Sector Scan” Command

- Simulated Doppler Radar

**Notes:**
Emphasize demonstrated in a lab environment to demo software concepts
Demonstration of dynamic instrument collaboration

## Sensor Web Research at GSFC An Autonomous, collaborative in situ marine fleet observing system (OASIS)

**Power:** Marine solar panels & marine batteries
**Iridium:** 2-way real-time communications
**Control:** Twin thrusters with internal rudder
**OBC:** G&N and sensor control
**Planned capabilities:** Grid mapping, dynamic surveying,  and station-keeping.

**Sensor Suite:**
-  - Microsalinograph; Fluorometer; Radiometers
-  - Wind Monitor; RH/Temperature Probe
-  - Precision Barometer;  GPS

- Dynamic Ocean Processes: Meanders, Frontal Instabilities,eddies

- Dynamically control fleet sampling strategy to observe a cold core eddy as it develops from the Gulf Stream and then sheds into the subtropical gyre.
- Potential use in real-time data assimilation efforts
- Harmful Algal Blooms
- Monitor their growth, map boundary, conduct *in* *situ* measurements

**Notes:**
Lead in with how expensive they are to construct, deploy, and especially retrieve
We’re building one and eventually a fleet
Distance, self-propelled and cost <$10K is our niche others cost $80K

## OASIS Platform Sensor WebGulf Stream Eddy Mapping and Nutrient Measurement

- Credit:

- Eddy Properties (e.g., boundary)
- Coordinate *in situ* and space based observations

- “Cold rings trap nutrient-rich water and transports nutrients and plankton into the relatively-barren Sargasso Sea” Credit:  Gulf of Maine Aquarium home page

## A large algal bloom......could a GSFC OASIS sensor web fleet have helped?

- Commercial fishermen along the Southwest Florida coast are reporting a massive dead zone that is almost devoid of marine life in an area of the Gulf of Mexico traditionally known as a rich fishing ground.
- They've dubbed it black water, and they're demanding that local, state and national government agencies find out what's causing it.
- Scientists who have heard of the phenomenon say they, too, need answers.
- "It's killed a lot of the bottom because recently a lot of little bottom plants are coming to the surface dead and rotten out in the Gulf," said Tim Daniels, 58, a Marathon Key fish-spotting pilot who has been flying over the Gulf for more than 20 years.
- Like Daniels, fishermen with decades on the water say they've often seen red tide but they've never seen anything like this — it doesn't have a foul smell, it isn't red tide and it isn't oil. They describe it as viscous and slimy water with what looks like spider webs in it.

*March 17, 2002*

- Credit: NASA Earth Observatory - SeaWiFS on Orbview-2

## Another Potential Sensor Web ApplicationHuman Health and the Environment

- Fixed and mobile sensors are placed in areas where humans cannot go or because it is too dangerous
- e.g., Exxon-Valdez oil spill
- Areas particularly vulnerable to oil spills
- Mud flats: can be up to several kilometers wide in the Cook Inlet/Kenai Peninsula region
- Can be dangerous environment for humans to work in
- A potential sensor web solution?
- A fleet of autonomous amphibious vehicles
- Perform collaborative mapping and contaminant measurements on exposed tidal/mud flats

- Sediment plume resulting from oil cleanup

## GSFC Sensor Web Concept Formulation

- Developed candidate sensor web definition
- Characterizing
- Node taxonomy and properties
- Node data reporting properties
- Sensor web classes
- Required sensor web architectural properties
- Identifying
- Science needs
- Candidate science scenarios and applications
- Developing
- Prototypes
- Models and simulations

## Node PropertiesLocation & Reporting Modes

- In space
- A single or a Distributed Space System (DSS) mission
- Within Earth’s (or planet’s) atmosphere
- Aircraft (e.g., UAV), balloon, sounding rocket...
- On the Earth’s (or planet’s) surface
- Fixed and mobile nodes
- Weather station, autonomous land/water craft
- Beneath the planetary surface or “skin”
- Submarine, subsurface sensors

*Deterministic*
- Node outputs information at a priori known times
- This does not necessarily mean a “fixed” time interval
*Triggered*
- Node reports information only when a predefined event, condition, phenomenon, or specified node operating state is detected
*On-Demand*
- Node reports information when requested by another node

## Class 1 Nodes Collectors

*A science data collector*
- Has *n *well defined distinct states (modes) of performing data measurements (i.e., *n* data collection modes)
- Mode m*i* of m*n* available modes may be *selected*  but *not modified*
- Transmits raw instrument data only
- Is unable to receive, and therefore cannot react to, data that is transmitted by another node
- Three Class 1 node types
- Passive Collector
- Active Collector
- Collector-Processor

## Class 1 Node The Passive Collector

- Input: collects raw science instrument measurements
- Data Processing: None
- One data collection mode
- Simply formats raw data for communications fabric transmission compatibility
- No science instrument state changes supported
- Output: raw science instrument measurements and instrument/node state data

- Node examples:
- Tipping bucket rain gauge
- Panchromatic, multispectral downlinked raw data stream with only one resolution, fixed FOV, etc.

- Raw Sensor Data

- Raw Instrument
- and Node State Data

**Node**

**Instrument**

## Class 1 Node The Active Collector

- Input: collects raw science instrument measurements
- Data Processing: Some
- Data collection mode changes are supported
- Science instrument mode (***M***) selection* by the node* using a simple function: ***M(i)***
- Output: raw science instrument measurements and instrument/node state data

- Node examples:
- River gauge node reports water level (***w***) measurements at more frequent time (***t***) intervals when node’s ***M(i) ***detects increasing ***dw/dt***
- Serves to maximize available comms bandwidth efficiency
- Send information that is most suitable to the sensed condition
- Spacecraft selects a sensor best suited to phenomena of interest (e.g., NIR vs. visible vs. UV)

- Raw Instrument
- and Node State Data

**Node**

**Instrument**

## Class 1 Node The Collector-Processor

- Input: collects raw science instrument measurements
- Data Processing:
- Fixed algorithm supported
- Instrument mode changes are supported as with Active Collector node
- Output: processed science instrument measurements and instrument/node state data

- Node examples:
- DMSP imager: records full resolution visible pixels and reduced resolution (averaged) IR pixels during day time passes and vice versa during nighttime passes

- Processed Instrument
- and Node State Data

**Node**

**Instrument**

*ƒ(x)*

## Class 2 Nodes Reactors

*Collect and react to data sent to it from a science instrument or from another node*
- e.g., water level gauge that can report data at one of *N* possible time intervals (1x per minute, 4x per minute, etc)
- Instrument and/or node has more than one mode of operation (i.e., data collection and/or processing)
- Two class 2 node types
- Collector-Reactor
- Reactor-Processor

## Class 2 Node The Collector-Reactor

- Input:
- Collects raw science instrument measurements
- Collects data from other node(s)
- Data Processing: None
- Output:
- Reacts to data/commands from other nodes and outputs raw science instrument measurements

- Node examples:
- River gauge reports water level (*w*) measurements at time (*t*) intervals
- In contrast to the Active-Collector node, _*another*_ node detects a *dw/dt condition *and commands a data collection rate change in the Collector-Reactor node

## Class 2 Node The Reactor-Processor

- Input:
- Collects raw science instrument measurements
- Collects data from other nodes
- Data Processing:
- Reacts to input data/cmds and outputs processed data
- Output:
- Processed science data and node state data

- Node examples:
- Future GOES-x meteorological spacecraft
- Numerical forecast model (A Science Processor class node) forecasts severe storm and commands GOES-x spacecraft (A Reactor-Processor Node) to begin rapid scan high-resolution imaging mode

- Raw Sensor Data

- Processed Instrument Data
- and Node State Data

**Node**

**Instrument**

- Commands & Data

- Commands & Data

*ƒ(x)*

## Class 3 Node Processors & Data Storage

*Are not connected to a science instrument*
- Input data from one or more other nodes
- Processor nodes transform received data into one or more higher level products
- Output stored data or processed science data products
- meteorological forecast model results
- remapped imagery
- synthesized science data (e.g., multispectral imagery and SAR combined to produce 3D terrain map)
- There may be many node types in this class
- Science processor
- Database, science archive...
- Orbit and attitude processor
- Scheduling and planning processor

## Class 3 Node The Science Processor

- Input:
- Collects data *only* from other nodes
- Output:
- Outputs processed science data
- Processed science data
- Model or simulation results
- Data Processing: Yes

- Node examples:
- A meteorological numerical forecast model
- A MHD model of the magnetosphere

- Processed Data (Science, Model, Simulation)
- and Node State Data

**Node**

- Commands & Data

*ƒ(x)*

## Class 3 Node The Data Storage Node

- Input:
- Collects data *only* from other nodes
- Output:
- Outputs stored data
- Data Processing: Perhaps. (e.g., Autonomous Data Mining)

- Node examples:
- GIS map database
- Archived science data
- Historical model runs
- Results of Data Mining

- Stored Data

**Node**

- Commands & Data

## Sensor Web Topologies

**Fully connected mesh**
-   Peer-to-peer
-   Distributed control
-   Equivalent functionality/capability at all nodes

## Sensor Web Topologies - continued

**Clustering**
-   Local command and control and sensor web data collection within each cluster
-   Reports to a “Master” overall control, monitoring, and/or coordinator node
-   A “cluster” may be a formation flying mission of ***N*** spacecraft; or subgroups of robotic explorers

- Master

## Sensor Web TopologiesReconfiguration – Node Aggregation

- Master

- And the sensor web “aggregates” into a new larger sensor web

- New Platforms Are Added at time ***t2***

- Sensor Web at time ***t1***

## Sensor Web TopologiesReconfiguration – Failure and Recovery

- Master

- Master

- Master Node Fails

- Then drones negotiate control and recombine to a new topology

- Master

- “Drone” Platforms Temporarily Assume Master Roles

- Master

## Sensor Web TopologiesReconfiguration – Cluster Mission Reassignment

- Master

- Master

- Master

- Cluster 1 temporarily “breaks away” and operates independently

- Then Cluster 1 rejoins the sensor web

- Master

## Sensor Web TopologiesReconfiguration – Cluster Reconfiguration

- Master

- Master

- Newly formed Cluster 1

- Master

- Cluster 1 nodes temporarily “break away” and  operate as independent nodes

- Then regroup to form a new Cluster

- Independent
- Platforms

## We can now build a range of Sensor Web Classes from these nodes types

-    Data collection and reporting (e.g., river water levels, incident solar radiation, lightning detection network, GOES DCS for data dissemination)
-    Data sharing (e.g., GPS-based time and location dissemination)

-    Event detection and notification (e.g., Swift GRB and the Gamma Ray Burst Coordinates Network - GCN)

-    Coordinated data collection and reporting, science data fusion, information synthesis, and decision making.

-    Collaborative system level reconfiguration (e.g., run new algorithm based on node data collected; deploy additional sensors/interrogate other sensors to refine forecast and alerts)

-    Intelligent sensor web predicts phenomenon, controls resources to perform collaborative observations, possibly even takes actions to modify effects of phenomena (e.g., predicts flash flood; monitors rainfall conditions; accesses GIS data; opens flood gates when flash flood detected)

***Class 1***

***Class 2***

***Class 3***

## Sensor Webs: Architectural Properties

- Heterogeneity
- Node types and reporting modes
- Communications fabric implementations
- Scalability
- Sensor Web nodes will almost certainly be required to “aggregate” over time
- Node population growth should not adversely affect sensor web functional or performance characteristics
- Logically combine two or more sensor webs into one virtual sensor web
- Sensor Web Control
- Centralized vs. decentralized peer-to-peer
- Local clusters

- Reliability, Recovery, Reconfiguration
- Handle failures, degradation
- Platforms: add, subtract, replace, upgrade/new functions
- Mobile nodes
- Accommodate changes in relationships of nodes
- Topologies
- Hierarchical, fully connected mesh, others...
- Clustering
- Data Management and Delivery
- Support data and services “discovery”
- Semantic and syntactic “seamless” data/information exchange
- Metadata representation & exchange
- Sensor Web Security

*"Life was simple before World War II. After that, we had systems.”*Rear Admiral Grace Murray Hopper

## Future Sensor Web Research

- Sensor Webs must evolve from a strategic plan concept to well defined science scenarios that can benefit from this new form of observing system and a mature suite of new information technologies with which they can be successfully implemented
- GSFC Earth scientists and information technologists are collaborating to identify and describe candidate science scenarios where sensor web information technologies will yield significant benefits to the science community
- We plan to develop additional Sensor Web prototypes to evaluate pragmatic information technology implementation issues
- Planning to use simulations and modeling techniques to assess candidate collaborative observing strategies
- Leverage existing technologies, infuse emerging new information technologies, and make investments to maximize the return of useful science

**Notes:**
This is how I think NASA should proceed

## So..where do we go from here?

- GSFC is seizing the opportunity to realize a Sensor Web vision and develop a viable capability for new Earth science observations, discovery, and understanding.
- Links to web resources:
- _[http://pioneer.gsfc.nasa.gov/public/sensorweb/current_research.htm](http://pioneer.gsfc.nasa.gov/public/sensorweb/current_research.htm)_
- Google searches on “Sensor Networks”
- Contact:
- stephen.j.talabac@nasa.gov