# Presentation: 800268

## An Information Systems Center (ISC)
Technology Education and Assessment Seminar (TEAS)

Presented by:
Stephen J. Talabac
May 16, 2002

- Technology Education and Assessment Seminar (TEAS)
- Presented by:
- Stephen J. Talabac
- May 16, 2002

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

- PRELIMINARY - ISC Sensor Web Concept Formulation

## Notice

*The information provided in these slides is not necessarily intended to represent NASA’s official view of Sensor Webs. Rather, these slides were prepared, with only nominal funding by the ISC, to:*
*explore concepts related to Sensor Web technologies and thus begin to develop a common understanding of their properties and their uses;*
*identify candidate science scenarios and new observation strategies (that are unique to sensor webs) that would clearly benefit the science community;*
*identify some of the research areas and activities by other organizations;*
*explore some of the issues associated with sensor web information technology (IT) architectural considerations*
*As can be readily discovered by searching the web for “Sensor Webs” there is a clearly a groundswell of active research within, and investment by, the Federal Government (notably DARPA) and academia.*
*The author hopes that the principal purpose of this presentation, to encourage open discussion and debate about this emerging idea, results in a systematic and rigorous approach by NASA to evolve Sensor Webs from simply a “concept” to an “engineering reality”.    **Stephen Talabac*

## Background

- NASA’s 2000 strategic plan, and the strategic plan of the agency’s Earth- and Space-Science Enterprises, identify “sensor webs” as a new paradigm for conducting future science observations.
*Yet...these strategic plans do not define the term “sensor web“.*
*There are many widely-varying and evolving views of:*
*what a sensor web “is“;*
*the intrinsic properties that a sensor web may possess; and*
*the various behaviors that a sensor web may manifest.*

## Sensor Webs:The Need for 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

- Establish evaluation criteria, evaluate candidate architectures, and select a reference architecture
- Identify the Information Technologies that will be required to implement the reference architecture
- Identify
- IT “gaps”
- IT R&D investments

## Agenda

- Background, terminology, and fundamental concepts
- A candidate sensor web definition
- Sensor web “nodes” and their properties
- A taxonomy of nodes
- Sensor web classes and their properties
- Representative sensor web scenarios that may benefit from the sensor web concept
- A survey of research activities
- Where should GSFC go from here?

## 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

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

## 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

## 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 protocol considerations like:
- Different models (e.g., 7 layer OSI vs. 5 layer Internet; virtual circuit vs. connectionless; etc)
- Low level protocols (e.g., media access, transport, routing, etc)
- Higher level protocols (e.g., guaranteed in-order packet delivery; file transfer services, etc)
- Signal processing
- Signal encoding scheme
- Uncompressed vs. Lossless or lossy compression
- Forward Error Correction (FEC)

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

- As is often the case with emerging concepts, there is presently no single, widely accepted, clear, and succinct definition.
- A candidate definition:
*A sensor web is a spatially distributed observing system, consisting of nodes that are interconnected through a communications fabric, and that functions as a single, highly coordinated, virtual instrument. It reacts to instrument observations and other information to determine *_*present*_* and *_*future*_* states of Earth- and space-science phenomena.*

*“**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

## 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

## Integrated Sensor Web Characteristics - Tomorrowe.g., Meteorology

- Composed of both space-and ground based in-situ platforms.
- Passive data collection is replaced by active targeting of key phenomena as a direct result of mathematical models that forecast probable future behavior with high precision and accuracy.

- Highly selective spatial and temporal observations provide additional critical information which significantly contributes to improve forecast models predictive ability.
- Data collected from a sensor web can serve to determine how future spatial and temporal observations can be planned and conducted.

## 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

## Code 588 Sensor Web Projects 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

## Code 588 Sensor Web Projects OASIS-Ocean Atmosphere Sensor Integration System

- ESTO FY02 Funded Prototype Research
- Oceanographic application in collaboration with Dr. John Moisan (GSFC/WFF)
- Self propelled, self-navigating surface vehicle to perform in-situ measurements
- Develop scenarios for fleet of collaborative sensor craft: e.g.,
- Dynamically control the sampling strategy of an OASIS fleet to observe a cold core eddy as it develops from the Gulf Stream and then shed into the subtropical gyre.
- Potential use in real-time data assimilation efforts

**Power:** Marine solar panels & marine batteries
**Iridium modem:** 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.
**Duration:** months
**Range:** 1000s km

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

**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e.g., Gulf Stream Eddy Mapping and Nutrient Measurement

- Eddy initial coordinates

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

- Credit:

## 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 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

## Node Properties - LocationAt any one, some, or all of these locations

- In space
- A single spacecraft mission
- A Distributed Space System (DSS) mission
- Within Earth’s (or planet’s) atmosphere
- Aircraft (e.g., “manned“, UAV), balloon, sounding rocket...
- On the Earth’s (or planet’s) surface
- Seismic gauge, rain gauge, drifting ocean buoy, autonomous surface craft
- Beneath the planetary surface or “skin”
- Submarine, earth digging device, subsurface strain gauges

## Node Properties - Data Handling

- A node _*must:*_
- Receive data from *at least one* of the following types of sources
- A Science Instrument that is connected to the node
- One or more nodes connected to the communications fabric
- Transmit data to *at least one* other node connected to the communications fabric
- A node _*may:*_
- Transform (i.e., perform data processing) any or all received data into one or more data output representations.
- Simply reformat the data
- Perform higher-level science data processing by applying a combination of algorithms, heuristics, ancillary data, etc.
- Transform raw measurements into scientifically meaningful/useful “information”

## Node Properties - Reporting ModesA node may support any or all of these modes

*Deterministic*
- Node outputs data *at a priori known times*
- This does not necessarily mean a “fixed” time interval
- e.g., once per minute; twice per hour
- e.g., when a spacecraft comes into contact with a ground station
*Triggered*
- Node outputs data *only when a predefined event, condition, phenomenon, or node/instrument state is detected*
- ocean salinity or phytoplankton measurements exceeds given threshold
- rain gauge or river water level gauge reaches defined level
- gamma ray burst occurs
- a cloud or specific cloud-type is detected
*On-Demand*
- Node outputs data *only when commanded by another node*
- soil moisture measurement is transmitted to a fire monitoring/prediction processor node

## Node Taxonomy

- Collector-Reactor

- Reactor-Processor

**Collector-Reactors**

***Science Instrument Nodes***

**Processors**

***Computing & Data Storage***
***Nodes***

- Plan & Sched.
- Processor

- Science Data
- Processor

**Storage**

- GIS Terrain Database

- Science Data Archive

- Orbit Determination
- Processor

- Numerical Model

- Science Algorithm
- Archive

- Passive Collector

- Active Collector

- Collector-Processor

**Collectors**

## 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: None

- Node examples:
- GIS map database
- Archived science data
- Historical model runs

- Stored Data

**Node**

- Commands & Data

## Node Summary

| Node Type | Node
Input | Data Processing Capability? | Node
Output | Commands/Node State Changes |
| --- | --- | --- | --- | --- |
| Passive Collector | Raw Science Instrument Data | No | Raw Science Instrument Data | Does not accept data input; Cannot be commanded; Instrument state changes not supported |
| Active Collector |  | Limited | Discriminated Raw Science Instrument Data | Cannot be commanded; instrument state changes are initiated by only the node to which it is connected |
| Collector-Processor |  | Yes | Processed Science Instrument Data | Cannot be commanded; state changes may be supported |
| Collector-Reactor | Raw Science Instrument Data
Data from other nodes | No | Raw Science instrument Data | Can be commanded to change state
 |
| Reactor-Processor |  | Yes | Processed Science Instrument Data | Can be commanded to change state; can accept new processing algorithms/code
 |
| Science Processor | Node Data | Yes | Processed science data (e.g., model output, high level science product, etc) | Can be commanded to change processing state; accepts input values for processing parameters; can accept new code for algorithms, etc |

## 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***

## A Proposed Sensor Web Taxonomy

| Sensor Web Class | Name | Platforms Used | Characteristics |
| --- | --- | --- | --- |
| 1 | Data Collection Sensor Web | Class 1 only: Passive Collector, Active Collector, Collector-Processor | Data is routed to processing site(s); collaborative science observing is not possible |
| 2 | Collaborative Science Sensor Web | Requires class 2 nodes (i.e., Collector-Reactor, Reactor-Processor). In addition, may also use class 1 nodes (i.e., Passive Collector, Active Collector, Collector-Processor) | Supports event detection, notification, response, and collaborative science observing. |
| 3 | Intelligent Sensor Web | Requires at least one Class 3 node (Science Processor) and must include Class 2 and/or Class 1 nodes.
 | Provides a predictive science capability working in concert with collaborative observations |

## Node Representations

| Node Class |  | Node Name | Node Icon |
| --- | --- | --- | --- |
| 1 | Collectors | Passive Collector |  |
|  |  | Active Collector |  |
|  |  | Collector-Processor |  |
| 2 | Collector-Reactors | Collector-Reactor |  |
|  |  | Reactor-Processor |  |
| 3 | Processors | Science Processor |  |

- PC

- AC

- CP
- F(x)

- CR

- RP
- F(x)

- SP

## Class 1 Sensor Web 

- Platforms perform data collection and reporting only
- Consists of Class 1 nodes only
- Examples
- NOAA GOES data collection system
- JPL “Sensors in the Garden”

## Class 1 Sensor WebPassive Collection with Periodic Science Reporting

- PC

- AC

- CP
- F(x)

- CR

- RP
- F(x)

- SP

- Communications
- Fabric

- PC

- PC

- PC

- PC

- PC

- Collects single-mode raw instrument data from nodes
- River water level data
- Full resolution data (TIROS HRPT)
- Instrument data is collected at node defined intervals
- 1x per hour
- When target is in S/C FOV
- Instrument data is reported at *a priori  *known intervals unique to each node
- Once per hour
- During ground station contacts
- A “batch” processing Ops Concept for science products
- Once every 3 hours

- PC

- users

- SP

## Class 1 Sensor WebActive Collection with Periodic Science Reporting

- PC

- AC

- CP
- F(x)

- CR

- RP
- F(x)

- SP

- Collects multi-mode raw instrument data from nodes
- River water level
- High resolution IR data during nighttime passes (DMSP)
- Instrument data is collected at node defined intervals
- 1x per hour; 1x per minute
- When target is in S/C FOV
- Instrument data is reported at *a priori*  known intervals unique to each node
- Once per hour
- Every ground station contact
- A “batch” processing Ops Concept for science products
- Once every 3 hours
- Science processing can take advantage of unique spatial and/or temporal instrument data collection properties

- Communications
- Fabric

- AC

- AC

- AC

- AC

- PC

- PC

- users

- SP

## Class 1 Sensor WebProcessed Collection with Periodic Science Reporting

- PC

- AC

- CP
- F(x)

- CR

- RP
- F(x)

- SP

- Collects and processes multi-mode raw instrument data from nodes
- River water level
- Full resolution & averaged FOV (TIROS AVHRR -  HRPT & GAC)
- High resolution IR data during nighttime passes (DMSP)
- Instrument data is collected at node defined intervals
- 1x per hour; 1x per minute
- When on-board orbit determination ID’s Earth day-night terminator
- Instrument data is reported at *a priori*  known intervals unique to each node
- Once per hour
- Every ground station contact
- A “batch” processing Ops Concept for science products
- Once every 3 hours
- Science processing can take advantage of on-board processing and unique spatial and/or temporal sensor data collection properties

- Communications
- Fabric

- AC

- AC

- PC

- CP
- F(x)

- CP
- F(x)

- CP
- F(x)

- CP
- F(x)

- CP
- F(x)

- PC

- AC

- users

- SP

## Example - Class 1 Sensor Web A Data Collection Sensor Web

- Ground
- Data System

-    Terrain/GIS databases
-    Node data collection
-    Node status monitoring
-    Flash flood alerts

- Rain gauge

- Rain gauge

- Anemometer

- River Water Level Gauge

- Communications
- Fabric

- Rain amount
- Time of measurement
- Location or node ID
- Node status

- Rain rate
- Time interval
- node ID

- Wind speed Wind direction
- Time
- Node ID

- Raw and processed node data

- Water level

- Water flow node

- Flow rate

- % soil saturation
- Node ID/location
- Node status
- Measurement time

- Soil Moisture Meter

- Rain data measurements

- Rain data measurements

- Wind speed/direction

- - Water volume
- - Time intervals

- Water level

- Soil moisture

- Alerts

- PC

- PC

- PC

- AC

- CP
- F(x)

- CP
- F(x)

- PC

- AC

- CP
- F(x)

- CR

- RP
- F(x)

- SP

## Class 2 Sensor Web

- Platforms perform data collection and reporting
- Instruments/nodes can change their state of operation
- Instrument data processing is supported
- Consists of Class 2 and possibly Class 1 nodes
- Platforms can be commanded to change instrument data collection state and/or data processing algorithm to perform
- Event detection
- Event notification
- Apply different processing algorithm
- State/mode reconfiguration

## Class 2 Sensor WebReactive Collection with Event-driven Science Reporting

- PC

- AC

- CP
- F(x)

- CR

- RP
- F(x)

- SP

- Collects & reacts to multi-mode raw instrument data from nodes
- River water level gauge is commanded to collect and report at more frequent intervals
- GOES S/C is commanded to Rapid Scan Mode
- Instrument data is collected at phenomenological defined intervals
- Localized heavy rainfall causes rapid increase in river/stream water levels potential precursor to a flash flood
- Instrument data is reported when measured conditions satisfy predefined criteria
- Other river water level sensors downstream are alerted
- A “batch” processing Ops Concept for science products
- SP initiated when reported conditions change

- Communications
- Fabric

- AC

- AC

- CP
- F(x)

- CP
- (x)

- CP
- F(x)

- CR

- CR

- CR

- CR

- users

- SP

## Class 2 Sensor WebReactive Processing with Event-driven Science Reporting

- PC

- AC

- CP
- F(x)

- CR

- RP
- F(x)

- SP

- Collects, processes, & reacts to multi-mode raw instrument data from nodes
- River water level gauge is commanded to collect and report at more frequent intervals
- Computes water flow in thousands of gallons per minute
- Instrument data is collected at phenomenological defined intervals
- Localized heavy rainfall causes rapid increase in river/stream water levels potential precursor to a flash flood
- Instrument data is reported when measured conditions satisfy predefined criteria
- Gallons per minute and ***dw/dt*** exceeds established threshold
- Other river water level sensors downstream are alerted
- A “batch” processing Ops Concept for science products
- SP initiated when reported conditions change

- Communications
- Fabric

- AC

- AC

- CP
- F(x)

- CP
- (x)

- CP
- F(x)

- RP
- F(x)

- RP
- F(x)

- RP
- F(x)

- CR

- users

- SP

## Example - Class 2 Sensor Web A Collaborative Science Sensor Web

- Ground
- Data System

-    S/C Ingest systems (L1-L4)
-    Terrain, GIS databases
-    Node: commanding,
-     data collection, status monitoring
-    Flash flood alerts

- Rain gauge

- Spacecraft (e.g., GOES, TRMM, TIROS, DMSP)

- Anemometer

- River Water Level Gauge

- Communications
- Fabric

- Rain amount
- Time of measurement
- Location or node ID
- Node status

- Rain rate
- Time interval
- node ID

- Wind speed Wind direction
- Time
- Node ID

- Node data

- Water level

- Water flow node

- Flow rate

- Soil Moisture Meter

- Future Spacecraft (with on-board processing)

- Rain gauge

- Scan mode Cmd

- Raw data D/L depends upon instrument mode

- S/C Cmds
- Ancillary data
- New Algorithm

- Processed Science Data

- Data collection rate Cmd

- Anemometer

- Scan mode Cmd

- Precipitation Estimator

- Cmds

- Cmds

- % soil saturation
- Node ID/location
- Node status
- Measurement time

- Alerts

- PC

- AC

- CP
- F(x)

- CR

- RP
- F(x)

- SP

- AC

- PC

- RP
- F(x)

- PC

- CR

- RP
- F(x)

- PC

- PC

- PC

## Class 3 Sensor WebPhenomenological-based Observing with “Intelligent” Science Reporting

- PC

- AC

- CP
- F(x)

- CR

- RP
- F(x)

- SP

- Collects, processes, & reacts to multi-mode raw instrument data and science processor models and other science algorithms
- Spacecraft (GEO, LEO) S/C are commanded to change observing modes, spectral bands, region of interest, etc) to collect observations in critical model forecast regions AND at key phenomena forecast times
- Instrument data is collected at phenomenological defined intervals
- Localized heavy rainfall causes rapid increase in river/stream water levels potential precursor to a flash flood
- Instrument data is reported to initiate SP new model forecast run
- Low pressure system does in fact develop but in different location
- A near-real-time Ops Concept for science products
- SP initiated when reported conditions change

- Communications
- Fabric

- AC

- AC

- CP
- F(x)

- CP
- (x)

- CP
- F(x)

- RP
- F(x)

- RP
- F(x)

- RP
- F(x)

- CR

- users

- SP

- SP

- SP

## Example - Class 3 Sensor Web An Intelligent Sensor Web

- Ground
- Data System

-    S/C Ingest systems (L1-L4)
-    Terrain, GIS databases
-    Node: commanding,
-     data collection, status monitoring
-    Flash flood alerts

- Rain gauge

- Spacecraft (e.g., GOES, TRMM, TIROS, DMSP)

- Anemometer

- River Water Level Gauge

- Communications
- Fabric

- Rain amount
- Time of measurement
- Location or node ID
- Node status

- Rain rate
- Time interval
- node ID

- Wind speed Wind direction
- Time
- Node ID

- Node data

- Water level

- Water flow node

- Flow rate

- Soil Moisture Meter

- Future Spacecraft (with on-board processing)

- Rain gauge

- Scan mode Cmd

- Raw data D/L depends upon instrument mode

- S/C Cmds
- Ancillary data
- New Algorithm

- Processed Science Data

- Data collection rate Cmd

- Anemometer

- Scan mode Cmd

- Precipitation Estimator

- Cmds

- Cmds

- % soil saturation
- Node ID/location
- Node status
- Measurement time

- Alerts

- PC

- AC

- CP
- F(x)

- CR

- RP
- F(x)

- SP

- AC

- PC

- RP
- F(x)

- PC

- CR

- RP
- F(x)

- PC

- PC

- PC

- SP

- Meteorological
- Forecast Model

- Sensor Web Node Inputs
- Forecast Outputs

## 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
- Should be able to logically combine 2 or more sensor webs into one virtual sensor web
- Sensor Web Control
- Centralized vs. decentralized peer-to-peer

- Reliability, Recovery, Reconfiguration
- Handle failures, degradation
- Platforms: add, subtract, replace, upgrade/new functions
- Mobile nodes (e.g., spacecraft, balloons, rovers, drifting buoys)
- Accommodate changes in relationships of nodes
- Varied Topologies
- Hierarchical, fully connected mesh, others...
- Clustering
- Data Management and Delivery
- Support data and services “discovery” (e.g., Jini)
- Semantically and syntactically “seamless” data exchange

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

- Identify and then evaluate candidate sensor web architectural alternatives.
- Of these candidate alternatives, which one(s) should be selected as a reference architecture?
- Map existing and emerging information technologies that meet the needs of the reference architecture.
- Identify a technology roadmap where IT gaps exist and where IT R&D investments are needed

## Links to learn more...

- http://pioneer.gsfc.nasa.gov/public/sensorweb/current_research.htm