senseit integration experimentation senseit pi meeting october 8 1999 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
SenseIT Integration & Experimentation SenseIT PI Meeting October 8, 1999 PowerPoint Presentation
Download Presentation
SenseIT Integration & Experimentation SenseIT PI Meeting October 8, 1999

Loading in 2 Seconds...

play fullscreen
1 / 29

SenseIT Integration & Experimentation SenseIT PI Meeting October 8, 1999 - PowerPoint PPT Presentation


  • 99 Views
  • Uploaded on

SenseIT Integration & Experimentation SenseIT PI Meeting October 8, 1999. Agenda. What Is Unique About SenseIT System Architecture Integration Process FY00 Experimentation. SenseIT provides a wide range of user benefits through integrated information technologies.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'SenseIT Integration & Experimentation SenseIT PI Meeting October 8, 1999' - admon


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
agenda
Agenda
  • What Is Unique About SenseIT
  • System Architecture
  • Integration Process
  • FY00 Experimentation
what is unique about senseit
SenseIT

provides a wide range of user benefits

through integrated information technologies

What is Unique About SenseIT

Unique User Benefits Provided by SenseIT

Enabling Information Technology

node architecture

Mobile

Code

InfoP

InfoP

Data Interest

Subscriptions

Security

Manager

Tamper Sensor

Node Architecture

High

Level

Info

GPS

Device

Status

(Local &

Neighbor)

Time

Series

Detect/

Classify

SigP

InfoP

Function

Manager

Data Acq. Module

Data Acq. API

Data Management Interface

Sensor HW

Message Handling

Repositories

Experiment Support and Control

Network Routing

Flow Control Services

Software

Modules

Communications API

Platform & O/S independent distributed services

Hardware

Components

Communications Hardware

data management interface layer
Data Management Interface Layer

Data Repositories and Functional Managers

Node Data

Repository

Access

[TS, DC, HI, DS]

Data

Sharing

& Trigger

Manager

Data

Subscribe

Manager

[DI]

Mobile

Code

Manager

[MC]

Query

Engine/

Proxy

Function

Request

Handler

Read

Access

Write

Access

S e c u r i t y S e r v i c e s

Network and Communications Layers

user platform architecture

Security

Manager

User Platform Architecture

Time

Series

Operator GUI

Experiment Monitor & Control GUI

DB Language Query Generator

DB Proxy Manager

Data Access & Store

Function Request Generator

Mobile Code Manager

Detect/

Classify

S e c u r i t y S e r v i c e s

High

Level

Info

Ethernet Connection

TCP/IP wrapped sensor net message

Device

Status

Gateway Passthrough

Message Handling

Mobile

Code

Network Routing

Flow Control Services

User Platform

Communications API

Gateway Node

Communications Hardware

philosophy
Philosophy
  • Need to keep a working system at all times
    • Facilitates research and experimentation
  • Strive towards hardware independence
    • Avoid limiting choices, hardware will evolve over time
  • Ability to juggle between research and experiments
  • Developers always invested in the process
schedule
Schedule
  • Integration schedule driven by experiment schedule
    • Experiments are critical to the success of the program
  • Detailed schedule in-progress
  • Identify dependencies and requirements now
    • Need resource estimates (CPU, memory) ASAP
    • Dependency specifications (at least) for December
  • Staggered schedule to reduce risk, ease development and integration
    • Integration task impossible if everyone delivers at once
    • Developers’ access to previously tested working code reduces problems
communications
Communications
  • Weekly Telecons
    • Tuesdays at 2P Eastern, 11A Pacific (tent.)
    • Starts October 12 (tent.)
    • Raise issues to the community
    • Identify schedule problems early
  • Quarterly Meetings
    • Jan 2000
    • Preparation for first experiments
  • Use senseit_all, senseit_pi, senseit_bbn
  • Integration website for documentation, other information (http://javamap.bbn.com:4840)
deliveries
Deliveries
  • Software
    • Needs to meet predefined system requirements to support experiments
    • May only deliver a subset of research development - research not completely driven by operational requirements
    • Upload software to website to begin integration testing process
    • Website holds repository of tested software available for download
  • Hardware
    • Delivered hardware catalogued and a sample set aside for configuration management
testing
Testing
  • Test procedures collaboratively developed ahead of delivery
    • Must address experiment needs
    • Can address research, other issues
  • Developers involved with testing process
    • Only people with complete understanding of delivered software
    • Testing complete and software available to community faster
  • Please, no software development during testing
    • Of course, bug fixes are OK
  • Tests run over two-week period
testing continued
Testing (continued)
  • Successful test completion
    • Interfaces with other delivered software
    • Meets predefined system functionality
    • Then released to others on website
    • Documented test results also available on test site
  • Debugging libraries
    • Need developers to contribute to and use debugging libraries
    • Lots of players in a small box
    • Test with and without debug
experimentation overview
Experimentation Overview
  • Experimentation Provides
    • Data for on-going development
    • Opportunities to showcase technologies in operational setting
    • Schedule Framework
  • Notional Plan
    • 1 field experiment / FY
    • 1 or more lab experiments / FY
    • Lab experiment is precursor to field experiment
  • FY00 Experiment
    • Initial plan in place
  • FY01&02 Experiments
    • Depend on achievable development schedule
fy00 experiment goals
FY00 Experiment Goals
  • Wring out basic end-to-end functionality & operability
  • Establish performance baseline
    • e.g. sensing performance, network traffic, latency, scaling, survivability, etc.
  • Highlight unique features (expand as devel. permits)
    • User Benefits
      • Multiple users/tasking, dynamic (re)tasking, basic collaborative processing
    • Enabling Technologies
      • Declarative languages, mobile code, advanced routing techniques, collaborative processing, tactical user interface
  • Gather data to aid PIs in further development efforts

Program must balance experiment “reach” vs. “risk”

Requires prioritization

fy00 experiment scenario overview
FY00 Experiment Scenario - Overview
  • Transporter Erector/Launchers (TELs) are on the move
  • Command needs to determine when and where they are moving.
  • Plan
    • Deploy sensor groups over a wide area.
    • Use sensors to determine TEL traffic patterns.
    • Send in Special Operations Force (SOF) to confirm identification and destroy TELs.
fy00 experiment scenario geography

Roads

FY00 Experiment Scenario - Geography

The scenario centers around a road intersection and a nearby chokepoint.

“Chokepoint”:

e.g. valley or village

fy00 experiment scenario sensor groups
FY00 Experiment Scenario - Sensor Groups
  • Sensors deployed and tasked by command with TEL/convoy surveillance.
  • Single function
  • Single Task

Group #1

Group #2

Sensor fields(10-15 nodes ea.)

Surveillance coverage

fy00 experiment scenario detected tel traffic
FY00 Experiment Scenario - Detected TEL traffic

Surveillance reveals that TELs frequently pass through the intersection to the “chokepoint”.

Apparent

TEL traffic

fy00 experiment scenario sof insertion
FY00 Experiment Scenario - SOF Insertion

Sensors continue TEL convoy surveillance for command.

  • SOF team inserts at chokepoint and tasks both sensor groups for full surveillance (truck, small vehicles, personnel)
  • Mobile code
  • Multi-tasked sensors
fy00 experiment scenario ambush
FY00 Experiment Scenario - Ambush

Group 1 sensors detect TELs moving towards chokepoint and alert SOF team

Team achieves positive identification, destroys targets and extracts

baseline scenario provides
Baseline Scenario Provides
  • Test basic “end-to-end” operation in realistic setting
  • Highlight unique SenseIT benefits & technologies
    • Multiple users/tasking, dynamic (re)tasking, basic collaborative processing
    • Declarative languages, mobile code, advanced routing techniques, collaborative processing, tactical user interface
  • Experimental data & performance to aid PIs, e.g.
    • Vehicle & foot traffic signatures
    • Detection/localization/tracking performance with different
      • sensor combinations
      • target types and densities
      • noise events
    • Statistics on network traffic loading and latency
  • Low risk expansion of scope as development permits
execution
Execution
  • Potential Locations
    • 29 Palms
    • Aberdeen Proving Grounds
    • Other
  • Traffic “Targets”
    • Heavy trucks, tanks, light vehicles (e.g. HMMVs), dismounted personnel, other
  • Target Timeframe
    • August 2000
  • Experimentation Practicalities
    • Use battery eliminators (i.e. nodes are AC powered)
    • Use Ethernet or other hard wired connection to collect data
    • Some level of experiment monitoring resides on each node
fy00 notional surveillance processing
FY00 - Notional Surveillance Processing

Node #1

Single Node Detection & Identification

Sensor #1

Sensor #M

Multi-Node Collaborative Localization

Tracking

Node #N

Single Node Detection & Identification

Sensor #1

Sensor #M

single node detection identification
Single Node Detection & Identification

Assume target signatures are dominated by unique tonals or lines

Narrowband processing: FFT, normalization & peak picking

Mic

Local “Intensity”

Acoustic Time-series

Exchange observations with neighboring nodes:

* Detect Target X

* Level = Y

Acoustic Line List

Compare to library of known targets

Target ID

Seismic Line List

Seismic Time-series

Narrowband processing: FFT, normalization & peak picking

Geo-phone

Local “Intensity”

Independent Process implemented on each Node

multi node collaborative localization
Multi-Node Collaborative Localization
  • Nodes share detection/intensity messages
  • All nodes that hold the target estimate target location
  • Candidate localization schemes
    • Location of maximum observed intensity
    • Geographically weighted sum of measured intensities
    • “Best fit” of measured intensities to very simple source/propagation model
tracking

X

X

X

X

X

Tracking
  • Automated track formation performed using simple data association algorithm
  • Locations plotted to visualize target position versus time