Distributed Services for Microsensor Networks Sensorware 2/3/2000 Jon Agre Rockwell Science Center.

Distributed Services for Microsensor Networks

Sensorware

2/3/2000

Jon Agre

Rockwell Science Center

• Improve Software Infrastructure for Sensor Nets

•Deterministic Realtime Embedded Environment

•Distributed Middleware Services

• Scalable, Deterministic, Efficient, High Performance

• Mobile Script Control

• Demonstration of Distributed Services Technologies

•Target Tracking with Mobile Script (using middleware services)

Objectives for Sensorware

Related Microsensor Projects - Candidate Software Functions for Middleware

• DARPA AWAIRS• Multihop Routing, TDMA Protocol, Self-organization, Beamforming Algorithms• Synchronized Array Data Collection Application, Detection Network Application

• ARL Sensors and Displays• Single-node Target Classification Algorithms for seismic, acoustic and magnetic, • Coordinate-based Displays, User Interaction Models, Hand-held Displays• Windows gateway (C++)

• Rockwell PLGR LAN• Multiple, slowly mobile user protocol (multihop)• GPS and positioning interface

• ONR Condition-based Maintenance (CBM)• Machinery diagnostics with High speed vibration, temperature, pressure• Web-based control Interface (Java)

• ONR Open Systems Architecture for CBM• Causal Network Diagnostics• Corba-based interface for distributed systems

Sensor Node Signal Processing Architecture

Continuous sample,HW filter,

threshold compare

Process singlesensor

Fuse multipleon-module sensors

Query/corroboratewith neighbors

Fuse featureswith neighbors

Beamformation

cooperativeIncreasing Quality

(decreasing false alarm rate,increasing detection rate)Higher Power Expended

Alarms may be reportedand awaken next layer

autonomous

User Interaction with Microsensor Network: Examples

• Inform sensor system to save/expend energy– no enemy activity expected; go to low alert (or vice versa: high alert)– friendlies or noncombatants entering zone; ignore– coverage by another sensor; sleep– unimportant area of operations for some duration

• Adjust energy expenditure in different dimensions– adjust level of decision detail (coarse - fine), both continuous and event-based– adjust required minimum latency (including heartbeat)– adjust required system lifetime

• Ask for more detail from one or a small set of select nodes• Inform network of likely targets - adjust Bayesian priors• Inform network of spatial character expected of targets• Inform network of new target type - provide new template• Provide network new signal processing software• Command network to increase covertness (LPD/LPI)

– remain radio silent until T minutes after target leaves area

User Interaction with Microsensor Network (continued)

• Inform network of conditions it cannot autonomously determine– from external sources; weather (hail, snow, etc.), muddy terrain, animal movements,

etc.

• Manually aid decisioning based on explicit knowledge or inference– deduce 2 reported targets are actually one

– help resolve target type based on deduction or fusion with external sources

• Inform network of impending addition of more nodes (overseeding) and when to expect it to occur

– network can expend more energy in anticipation of resupply

– will adjust network entry access protocol to speed process and save energy

– disconnected networks can anticipate bridging (merging)

Lifetime

Rapidity of info (latency -1)

Detail and/orCertainty

User selects performance:

EG H

D

I

J L

M

N

OMHC1

MHC2

MHC3

F

AB C

MHC4

MHC5 K N32d22m12.95966sW84d48m17.34192s

Published data in whiteProjected data in red

Reference pointNorthing=M4, Easting=MHC5Drawing coordinates use this as 0,0N32d22m11.58487s, W84d48m20.56715s

Situation Awareness in MOUT

Exercise at Ft Benning McKenna MOUT Facility

GPS Receiver Local Area Network (PLGR-LAN)

• Low cost situational awareness and messaging tool for the warfighter.– Allows for localized C2 for

the squad or platoon in an urban environment

• Can also be used with distributed sensors to provide additional intelligence gathering and alerting capabilities.

RockwellCollins

Condition-based MaintenanceFailure Prediction for Individual Units and Complex Systems

• Condition-based Maintenance/Failure Prediction

–Motor Failure Prediction

–Process Monitoring

–High Value / Critical Asset Monitoring

–Systems Monitoring

• CBM / FP Provides for:

–Substantial Maintenance, Logistics and Unscheduled Down-time Cost Savings

–Manpower Reduction

–Increased Safety

Internet-based Demonstration of WINS for CBMWINS Nodes In Chilled Water Pump Room

Ten wireless nodes transmit temperature and vibration information to the basestation node -> internet server

http://wins.rsc.rockwell.com

BasestationNode

WebServer

Sensor Node Iconspresent summary color-coded bar graphs of bearing health indicators for quick problem identification.

Gray colored icons are motors that are presently turned off.

Internet-based Demonstration of WINS for CBM

WINS Network - Main Screen

Java Applet running on WINS webpage.http://wins.rsc.rockwell.com

Ball Pass Frequency, Inner RaceFault frequency and 19 harmonics

Bearing Diagnostics Report

Baseline Reading

Largest Reading

Double clicking on icon brings upBearing Diagnostics Detail Screen

Adjustable scale settings

Poll sensor nodes for another test result

ONR OSA-CBM Overall Program Goals

• Develop an integrated, condition based monitoring (CBM) system– define the software infrastructure (or middleware)

• define groups of software interfaces for each OSA-CBM layer

– use existing standards if available– define non-existing standards

• Demonstrate OSA-CBM capability– demonstrate capability and usability of developed standards on

different diagnostic platforms (RSC Nodes)

TRANSDUCER

SIGNAL PROCESSING

CONDITION MONITORThe highest layer of machine data

DATA ACQUISITION

HEALTH ASSESSMENTThe lowest layer of embedded human intelligence

DECISION SUPPORT

PRESENTATION XML

1451.X

SENSOR MODULE

Presentation layer is the man/machine interface. May query all other layers.

Decision support utilizes spares, logistics, manning etc. to assemble maintenance options.

Health Assessment is the lowest level of goal directed behavior. Uses historical and CM values to determine current health. Multi-site condition monitor inputs.

CM gathers SP data and compares to specific predefined features. Highest physical site specific application.

Signal Processing provides low-level computation on sensor data.

Data Acquisition- conversion/ formatting of analog output from transducer to digital word. May incorporate meta-data. Ala. 1451.X

Transducer converts some stimuli to electrical signal for entry into system.

The Vertical Arrows indicate Process (Logic)

flow, the Red Arrows indicate Network (connection) flow.

HTML XSL

PROGNOSTICSPrognostics considers health assessment, employment schedule, and models/ reasoners that are able to predict future health with certainty levels and error bounds.

XML

XML

XML

XML

XML

MIMOSAOPCSTEP

OSA/CBM (PROPOSED)

XML

Sensorware Progress• Task 1: Requirements Definition

• SensorWare Operating System selected after evaluation • MicroC/OS - C-based, open source, lightweight, realtime OS, modifiable

• Base middleware capabilities being defined in conjunction with SenseIT• Several specialized sensor network services defined

• System Coverage• Signal Processing Architecture Stack (from AWAIRS)• Synchronized Sampling• Spatial-based Communication

• Implementation of middleware will be in both Windows CE and MicroC/OS• Task 2: Low Level APIs

• Draft version of C-based API document • Architecture improvements - (e.g., interrupt handling, radio interface) - Coding in progress• API Implementation - Coding initiated• Reference Applications (Dlog, Detection Net) - Coding in progress• System and software provided to UCLA• Port of Gateway DLL to Windows CE - Nearly complete• Emulation of PlatformConnect Windows CE to allow execution of SenseIT - Coding• Sensor.com API will be supported as feasible

• Task 3: Middleware Services• Mobile Scripting implementation - (UCLA)• New Coverage determination algorithm under investigation

• Task 4: Sensor Node Improvements• New Processor Board

• Increased SRAM (1 Mb) and Flash (2 Mb)• Parallel Bus Interface• Two RS-232, USB, Watchdog

• New Sensor Modules• Acoustic• Accelerometer

• New Package Design• Rechargeable batteries• Solar power

• Task 5: Demonstration and Integration• Target tracking with mobile scripts demonstration on track• Joint demonstration of capabilites planned with DSN Project (ISI, VaTech, UCLA)

Sensorware Progress (cont)

•

Parallel Interface

Power SupplyBatteries

ProcessorRadio

SeismicMagneticAcoustic

Geo

Solar Cell

Power Supply(TOP)

Processor(Bottom)

Processor(Top)

Serial Interface

Sensor Side

Improved Sensor Package

GPS*

*Design Only

Middleware Services• Base Services (Defined in Conjunction with SenseIT)

• Communications Protocol Stacks• Signal Processing Stack• Power Management• User Interaction• Network Synchronization• Query Processing• Configuration (Bootup, health status, maintenance)• Fault Tolerance• Security/Authentication

• Specialized Services • Mobile Script• System Coverage (Sensing)• Synchronized Sampling

• Spatial-based Communication

•Middleware Working Definition: A software function(task) that satisfies:

• At least two applications use the function, or• the applications need to run on at least two different type platforms

•Middleware has two primary functions• Stitch together low-level APIs (Platform Dependent) to implement service transparently to application• Provide distributed resource management/allocation (Field Organization)

• e.g., More global knowledge is necessary• Network-wide power management• Computation performance optimization

What is Middleware?

Application

Middleware

Low Level APIs

(at Source)

Physical Layer

Peer-to-peer

Master Cluster

SendMsg(A,synch(B))SendMsg(B,synch(A))SendMsg(A, RouteData(C))SendMsg(B,RouteData(C))

Need to Synchronize Samples of A and B and Send to C for Processing

SampleSynch(A,B): RouteData(A,C): RouteData(B,C):

SendMsg(M2, synch (A,B))SendMsg(M2, ReturnData((A,B),C)

A

B

A

B

CC

M1M2

M2:SendMsg(A,B, synch) M2:SendMsg(A,B ReturnData) M2:SendMsg(A,B,Sample) ... A:SendMsg(M1, Data) B:SendMsg(M1, Data) M2:Msg(M1,RouteData(C))

A:SendMsg(B, synch) A:SendMsg(B, ReturnData(C) A:SendMsg(B, Sample)... A:SendMsg(i, Data(C)) B:SendMsg(i, Data(C))

D

D

Middleware Example

Low Level APIs

(at Node Participants)

Coverage Service• Sensor Coverage Performance Characterization

• Boundaries (perimeters)• Density• Susceptibility to Breach

• Scalability• Bounded answer: quantization/compression• Bounded Messaging Throughout Process of Determining Answer• Spatially bounded query/response

• Algorithm• Distributed, incremental computation• Guaranteed termination• Efficient communications network support

• Instantiation• Global characterization executed at bootup• User-activated query

• Generalization• Viewpoint-dependent resolution; distributed database updates

(Assume that each sensor node knows its position.)

Coverage Performance Characterization

• Coverage Boundaries• Given sensor detection range R, find

the curve(s) that enclose the area covered by the sensors.

• Generally there may be many curves due to “holes”; concern for scalability.

• Density of Sensor Field• Define in terms of distances

associated with Voronoi vertices.

• Susceptibility to Breach• A breach will be attempted between

a given origin and destination. If the path having the least likely detection is taken (a geodesic), what is the detection probability?

• Optimal path will occur along Voronoi edges.

• Generalization: Origin/destination selected from point set (e.g., line segment or region)

Approximatecoverage boundary

Breachdestination

Breachorigin

Radius ofDelaunay circlecharacterizes

Voronoi vertex

Sensor node site

Conclusion

• All Tasks on track or ahead of schedule

• Team in place and working with prototype sensor nodes and user interface software

• Several new subtasks incorporated to insure integration with other SensIT projects

• Joint demonstrations with DSN team (ISI, VaTech, UCLA) planned for August FY00, FY01 and FY02

•Target Tracking with Mobile Scripts planned for August Demonstration