data sharing middleware prototype (dsmp) for information dissemination among heterogeneous sources

Managed by UT-Battelle for the U.S. Department of Energy – Supporting the Department of Homeland Security

Data Sharing Middleware Prototype (DSMP) for Information Dissemination

Among Heterogeneous SourcesQuarterly Review Meeting, January 21, 2009

Hairong Qi (PI), University of Tennessee

Xiaorui Wang (co-PI), Seddik Djouadi (co-PI), UT

Oak Ridge National Laboratory*

Oracle Corporation*

Microsoft Research

Rutherford Appleton Laboratory, UK*

* Oracle, Microsoft Research, and ORNL verbal commitments for in-kind support (consulting and research software)


Contact Information

• Academia– Hairong Qi, 865-974-8527, [email protected], 1508 Middle Dr., 319 Ferris Hall, EECS Department,

University of Tennessee, Knoxville, TN 37996– Xiaorui Wang, 865-974-0627, [email protected], 421 Ferris Hall, UT– Seddik Djouadi, 865-974-5447, [email protected], 307 Ferris Hall, UT– Raghul Gunasekaran, 865-385-5857, [email protected], 536 SERF, UT– Ming Chen, Ying Sun, Samir Sahyoun, Ben Taylor, UT Graduate Students

• Research Laboratories– Frank DeNap, 865-576-8786, [email protected], Oak Ridge National Laboratory, PO Box

2008, MS6085, Oak Ridge, TN 37831– Mallikarjun Shankar, 865-574-2704, [email protected], Oak Ridge National Laboratory, PO

Box 2008, MS6085, Oak Ridge, TN 37831 – Steve Fisher, RAL, [email protected], Rutherford Appleton Laboratory (RAL), UK

• Industry, Private sectors– Dieter Gawlick, Ronny Fehling, Aravind Yalamanchi, 650-560-8706, {dieter.gawlick, ronny.

fehling, aravind.yalamanchi}@oracle.com, Oracle Corporation

– Vijay Dialani, Microsoft Research Center


Collaborative Team

• Academia– University of Tennessee– Vanderbilt University

• Research Laboratory– ORNL (Oak Ridge National Laboratory, US)– RAL (Rutherford Appleton Laboratory, UK)

• Industry– Microsoft Research– Oracle


Project Description

• The objective of this project is to develop a data sharing middleware that is able to handle multiple distributed data sources and dynamically changing items, and to assist in real-time information dissemination across multiple agencies for homeland security purposes.

• The ultimate target scenarios are first responders and consequence response at the urban area of Memphis (e.g., Shelby County) with stakeholders including the Fire Department, Weather Services, the E911 Operations Center, Law Enforcement Agencies, etc.


Minutes from Last Quarterly Review Meeting

• General discussion– Can INFOD behave like an aggregator?

– Can there be registry of registry?

– Human factors of INFOD haven’t been discussed (e.g., no sight, no hearing)

– Clarify the difference between the traditional model and the INFOD model

– Security is an essential issue to be discussed in INFOD

– Different consumers should have different right time to receive the message

– Suggest to demonstrate INFOD in a more confined environment

– Make closer connection of INFOD and the real-time meta-data modeling

– The uniqueness of the proposed plume tracking model should be clarified and emphasized. Instead of moving the sensors, we can think about a sensor grid

– Need to design a scenario where under the same setup, INFOD would make a difference

– Comments on client-side development

• Pre-meeting discussion on Privacy with data sharing systems– Frances Butler and Janet Murrill


Landscape AssessmentTraditional Model

Publisher

PublisherConsumer

Consumer

Subscriber (Subscription)INFOD RegistryPublisher

Publisher

Consumer

Subscriber/ Consumer

Repository

INFOD Model

• Existing pub/sub systems– Topic-based, Type-based, Content-based– Message-oriented Middleware (MOM)

• Service-oriented system (binding AFTER event)

• Repository – data center, processing center• Static system. Extending the system is

difficult.

• Establishes a framework for info flow• Matches publishers and consumers based

on information needs expressed through subscriptions and limited by properties

• Event-based system (binding BEFORE event)

• Registry - NOT a data (event) repository• Better handling of dynamics. Extensibility is

good. (Vocabulary, e.g., NIEM)

Alerting system

Consumer/Publisher

Right Info Right Person @ Right Time

Push

Pull

Push

Push


INFOD Components and Setup Procedures

Consumer

Subscription

Data Vocabulary

Data SourceEntry

Property Vocabulary Instance

Creation of resource

Notification (by INFOD registry)

Reference (EPR)

Notification (by Publishers)

INFOD Registry

Entry Resource – not an entry

ConsumerPublisher

Subscriber

Property Vocabulary

PublisherEntry

SubscriberEntry

ConsumerEntry

1. Register community property and data vocabularies in the INFOD registry

2. Define subscriptions binding entities, defining events and which entity needs to be alerted on which other entities presence.

3. Entities register to the INFOD registry

4. Perform matching and notification message sent to matched entities.


Today’s Presentation Outline

• Development track– Demo: INFOD Web Application - Raghul

Gunasekaran

• Research track– Real-time Metadata Matching in INFOD - Ming Chen – Application Scenario: Chemical Plume Tracking -

Samir Sahyoun

• Discussion of future plan


Collaborative Opportunities

• Y-12– Privacy policy and NIEM

• ORNL– Testbed setup– Emergency plan

• Oracle– In-kind support

• MSU– Real-time operations support for emergency evacuations

• UT - Emergency Plan Team• All the research findings and software developments are accessible

through public domains, maintained at UT– http://panda.ece.utk.edu/wiki/InfoD


Project Timeline

• The development of the DSMP (Task 1.2) has been divided into a 4-phase implementation plan. Because of the close collaboration with Oracle, Microsoft Research, ORNL, and RAL, we are able to finish all four phases of prototype development ahead of schedule.

• Phase 1 - simplest scenario with a known data vocabulary and a trivial subscription• Phase 2 - 2 publishers services, 2 consumer services with the addition of property vocabularies• Phase 3 - multiple data vocabularies, publish, consumer, and subscriber services• Phase 4 - a standard notification interface

Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4Task 1: Design, Development, and Evaluation of the DSMP

Task 2: Demonstration of the DSMP

Task 2.3: Application scenario 3 - first responders and consequence response

Task 2.2: Application scenario 2 - establishing data correlation

Task 1.2: Prototype design and developmentTask 1.3: Middleware performance evaluation and refinement

Task 2.1: Application scenario 1 - collaborative event analysis

06/07 - 05/08 06/08 - 05/09Tasks

Task 1.1: Literature survey and document study


Budget Information

• Project budget (June 5, 2007 - May 31, 2009): $400,000

• Spending as of December 31, 2008: $250,759.16


Commercialization Progress

• The INFOD working group is approached by OGC (Open Geospatial Consortium) to join the consortium. This would help getting more publicity of the product on geospatial and location based services

• Potential feature to Oracle product line


IP STATUS

• Open source development– Will be available through sourceforge to

stimulate broader participation


Achievements• Finished all four phases of the prototype development (ahead of schedule)• Papers accepted

– “Control-based real-time metadata matching for information dissemination,” 14th IEEE Int. Conf. on Embedded and Real-Time Computing Sys and App, Taiwan, August 2008. (Acceptance rate: 26%)

– “Dynamic target classification in wireless sensor networks,” Int. Conf. on Pattern Recognition (ICPR), Tampa, FL, December 8-11, 2008.

– “Source localization using stochastic approximation and least squares methods,” 2nd Mediterranean Conference on Intelligent Systems and Automation (CISA'09).

• Students graduated– Y. Sun, Dynamic Target Classification in Wireless Sensor Networks, MS Thesis, Summer 2008.

• Presentations – “INFOD Use Case Scenario & Demo,” Open Grid Forum (OGF), Feb 2008, Boston– “An INFOD Reference Implementation,” Open Grid Forum (OGF), Oct 2007, Seattle

• Papers submitted/in-preparation– “Dynamic cyber-attack detection and classification based on the information dissemination model”– “Plume estimation and tracking using mobile sensors,” To be submitted to IEEE Conference on

Decision and Control 2009.– “INFOrmation Dissemination middleware”


INFOD Development

Raghul Gunasekaran


Implementation Model

ORACLE PL/SQL

INFOD Registry Service

OC4JINFOD

Web Service

ORACLE 10g

PL/SQLJava procedures

Client Environment

INFOD Spec.

PostgreSQL Database

Clie

nt L

ibra

ry

Stage 1Stage 2 – INFODweb

Web Management Interface

Tomcat

Publisher App/ Service

Stage 3

ConsumerApp/

Service

Client Applications

ServletsServlets

app.jar : API for communication between applications and INFODweb.


Mutual Filtering – INFOD Registry

Publisher Constraints

Consumer Constraints

Meta Data

PublisherConsumer

Subscriber/Subscription

Meta Data

Consumer Constraints

Subscriber Constraints

Publisher Constraints

Meta Data

Subscriber Constraints

Note: All constraints and meta data (in identical colors) needs to be evaluated and MUST be true for communication between a publisher and a consumer.


Meta Data

Subscriber constraint

Consumer constraint

Publisher URI

Meta Data

Subscriber constraintPublisher constraintConsumer URI

Meta Data

Consumer constraint

Publisher constraint

SubscriptionURI

Publisher Subscriber

Consumer

Consumer RowID

Publisher RowID

Publisher Consumer Mapping

DataSource RowID

Consumer RowID

Subscription RowID

Match results

Subscription RowID

Publisher RowID

Publisher Subscription Mapping

Consumer RowID

Subscription RowID

Consumer Subscription Mapping

Mutual Filtering – INFOD Registry


No. of Entities

Method 1 seconds

Method 2

100 0.4 3.5 sec

200 0.9 < 1 min

400 1.4 1.5 min

600 1.9 2.2 min

800 2.3 3 min

1000 3.8 ~4 min

Method 1 – No intermediate StepMethod 2 – Intermediate Mapping table

Table 1: Mutual Filtering time for meta data with 500 XML elements and no. of entities representing the number of publisher, consumer and subscribers individually.

INFOD Registry – System Performance

Plot 1 – System Scalability

Plot 2 – Performance w.r.t. constraints for 500 entitiesM1 – All constraints; M2 – No constraints on Subscriber


INFOD ‘Hello, World!’ Example


Use Case description

Scenario

An accident has occurred, and a bystander reports the event to the E911 center. The E911 center then requests for police, ambulance and/or fire truck to be dispatched based on the current description of the event. As the first officer arrives at the location, the officer reports more details of the accident to the E911 center and also updates on the developments and states of the incident. The E911 center based on the description of the event and the current state of the event alerts the necessary services (fire, medical and police) for action. If resources in a particular region are not sufficient, then the E911 center needs to make a decision in calling for additional resources based on their capabilities and availabilities.


Use Case descriptionSetup

• The E911 center receives information of any emergency within an area, and based on the incident information it communicates with first responders such as police, hospital, fire and medical services. The E911 center operates closely with the police (control center)

• The police control center instructs and maintains information of its resources in an active duty. Similarly, the fire service and medical services control and command over their resources.

• The E911 center instructs these control centers and the control center communicates to their resources.

The example scenario here is to demonstrate the functioning of INFOD. The scenario might not completely reflect the real world. The goal behind this demo is to have a simpler version of the real world for developers/collaborators/users to understand how INFOD functions.


First Responder Use Case

E911 Center MedicalEmergency

Service

Fire Service A

Hospital B

Hospital A

Fire Service B

Accident

Observer

Police Control Center



ServicePolice Control Center

Fire Service A

Hospital B

Hospital A

Fire Service B

Accident

Observer

Officer at Accident spot

First Responder Use Case


INFOD helps • Monitor resources

• All entities registered in the system

• Gain knowledge of the capability/availability of the resource• In terms of property vocabulary instances

• Associate entities (Publishers – Consumers)• Handle incident objects

• What defines as event at the publisher• Policies/ constraints which need to be enforced based on the event

description• Select consumers (dynamic consumers) based on the event

INFOD - First Responder Use Case




ServicePolice Control Center

Fire Service A

Hospital B

Hospital A

Fire Service B

Accident

Observer

Consumer

Consumer

Consumer

Publisher

Datasource/ Consumer

DataSource/ Consumer

Consumer

Consumer

ConsumerConsumer

Consumer

INFODRegistry

Consumer


INFOD in 4 steps1. Register community property and data vocabularies in the INFOD

registry

2. Entities register to the INFOD registry• Create Publisher, Consumer and Subscribers • Create and update property instances – Meta Data

3. Define subscriptions • Property Constraints – on Meta Data• Data Constraints – policies/ event constraints• Dynamic Consumer Constraint – identify consumers based on event

4. Mutual Filtering in the INFOD registry and notification message sent to matched entities.



INFOD Web Services

Step 1 : Register Property and Data vocabularies for a community


Property Vocabulary

Predicates Description

OrganizationName Name of the entity

OrganizationDescription Description of the entity

OrganizationType Enumeration Type classifying the organization (Police, FireService, MedicalService, Hospital)

Location Location of the organization

Resources Description of the resources

ResourcesType Enumeration Type(FireTruck, Ambulance, Police, Helicopter)

ResourceStatus Enumeration Type on the availability(0 – Active on duty and not available, 1 - Available for emergency)

ResourceLocation Location of the resource


Data VocabularyPredicates Description

Event Details like number of people involved, number of buildings affected, text description of the event,

EventLocation Location

EventCategory Geo, Met, Safety, Security, Rescue, Fire, Health, Env, Transport, Infra, CBRNE, Other

EventCertainty Very likely, Likely, Possible, Unlikely

EventSeverity Extreme, Severe, Moderate, Minor

ResponseType Shelter, Evacuate, Prepare, Execute, Monitor, Assess, None

ResponseAction Text description of the response action

EventScope Public, Restricted, Private

EventStatus Actual, Exercise, TestUrgency Immediate, Expected, Future, Past


INFOD Web Services

Step 2 : Create Consumers and Publishers

Property Constraints

for $publishers in fn:collection("$$INFODpublisher") where $ publishers //OrganizationSubUnitName=”RedCross”


INFOD Web Services


Property Constraintsfor $publisher in fn:collection("$$INFODpublishers") where $publisher//OrganizationSubUnitName=”E911Center”for $firstresponders in fn:collection("$$INFODconsumers") where $ firstresponders//OrganizationSubUnitName=”RedCross”

Data Constraintsdeclare namespace $data = http://infod.firstrespondernet.com/AlertDataVocabulary; let $msg1 := for $firstresponders where $data:AlertStatus = ‘Actual’ and

$data:EventCategory = ‘CBRNE’ and $data:EventSeverity > ‘Moderate’

return {$data, $data:Instruction = ’Evacuate people in the region’ } let $msg2 := for $firstresponders where $data:capAlertStatus = ‘Actual’ and

$data:EventCategory = ‘Fire’ and $data:EventSeverity > ‘Moderate’

return { $data:Substance, $data:Volume, $data:EventCategory }

Dynamic Consumer Constraint for $firstresponders where $firstresponders//OrganizationSubUnitName=”Police” return msg1 for $firstresponders where firstresponders//OrganizationSubUnitName=”FireService” return msg2

INFOD Web Services

Step 3 : Subscribers and Subscriptions


INFOD Web Services

Step 4 : Notification Messages


Integrated Control of Matching Delay and CPU Utilization in Information

Dissemination Systems

Ming Chen, Ben Taylor, Xiaorui Wang


Information Dissemination System

• Hundreds even thousands of subscriptions are registered;

• Different subscriptions have different priorities and different costs to evaluate

• Updates arrive with unpredictable intervals

• Valuable Information at the Right Time (VIRT).


Challenges

• The time of reevaluating a subscription may vary significantly.

• Updates may arrive at any inter-arrival intervals

• Reevaluating all subscriptions may cause severe system workload and unacceptable long delays

• We can NOT trigger all subscription reevaluations upon each update.

• We can NOT accurately calculate how many subscriptions to reevaluate to meet with the specified matching delay.


Solutions

Batching window Hong long?

Subscriptions Hong many?

Our goals: matching delay system throughput


Architecture• Integrated controller: to control both response time and

CPU utilization• Admission controller: to enforce maximum average

matching interval for low-priority subscriptions


System Modeling• Relationship between the

matching delay and CPU utilization and the batching window size and job budget.

• System identification (Matlab)

• White noise.

• Randomly choose a job budget such that the CPU utilization > 50%.

Difference Equation

System Model


Controller Design19.3824 21.2958

0.1289 0.1655IK =− −⎛ ⎞

⎜ ⎟−⎝ ⎠20.4599 24.4225

0.1334 0.1960PK− −⎡ ⎤

=⎢ ⎥−⎣ ⎦

• Larger Q leads to faster response to workload variations;• Larger R makes the system be less sensitive to system noise;• LQR controller is designed by using the Matlab command dlqry to solve the optimization problem.

LQR controller:


Experimental Setup• Two servers

– Server1: INFOD system, Oracle 10g– Server2: Java code to simulate requests from

consumers, publishers, etc

• JDBC connectivity• Updates follow a Poisson process• Set point

– 2s for matching delay– 0.8 for CPU utilization– 10s for low-priority subscription reevaluation


Exp 1: Selection of set points of CPU utilization

• a trade-off between the control accuracy and the

system throughputs.


Exp 2: Control performance

• Show the control performance of the integrated controller by comparing it with the open-loop system.

oscillations Overloaded


Exp 3: Comparison with baselines

• Delay-only• Util-only


Exp 4: Admission controller

• Control performance of the admission controller


Future Work

• Stability analysis on model variations− different platforms;− different execution time of subscriptions;

• More analysis on the admission control


Chemical Plume TrackingProgress and Future work

Samir S. Sahyoun

Advisor: Seddik M. Djouadi


Contents

• Summary of Achievements till Last Meeting

• New Results

• Future Work


Summary of Achievements till Last Meeting


Source Localization

• Plume source location is estimated using a grid of fixed sensors

• Two approaches have been developed: Non-Linear Least SquaresStochastic Approximation


Source Localization

Number of SensorsError (m)

Non Linear Least Squares

Stochastic Approximation

10 197 84

20 79 22

Results and more details are in

S. Sahyoun, S.M. Djouadi and H. Qi, Source Localization using Stochastic Approximation and Least Squares Methods, accepted for presentation in the 2nd Mediterranean Conference on Intelligent Systems and Automation (CISA'09).


Plume Boundary TrackingProcess Block Diagram

• Plume Estimation using State Space Model• Plume Boundary Prediction and Tracking with Mobile Sensors• Closed loop LQR Control of the Sensors


Plume Boundary Tracking

• Working Paper : S. Sahyoun, S.M. Djouadi and H. Qi, Plume Estimation and Tracking using Mobile Sensors. To be submitted to IEEE Conference on Decision and Control 2009.


New Results


Source Localization using Mobile Sensors

• Advantage: Smaller number of sensors needed. Used only four sensors in experiment

• Procedure:

- Sensors estimate the source Location

- Self distribute around estimated source

location

- New estimate is generated

- Process repeated till convergence to

the actual source


Source Localization using mobile sensors

QuickTime™ and a decompressor

are needed to see this picture.


Plume Boundary Interpolation

• Objective: Approximate Plume Boundary from Sensor measurements

• Interpolation process is needed to estimate the shape of the plume boundary

• The larger number of sensors the closer the shape to the real plume boundary

• Spline Interpolation technique is used


Interpolation

-81.28 -81.26 -81.24 -81.22 -81.2 -81.18 -81.16 -81.14 -81.12

36.62

36.63

36.64

36.65

36.66

36.67

36.68

36.69

36.7

36.71

36.72

x(KM)

y(KM)


Future Work


Future Work

• Apply Developed Procedure to Different Types of Plume Models (Lagrangian, Euler, etc.)

• Currently sensors controlled independently.• Need: Mobile Sensors Distributed Coordination for

- Source localization rendez-vous problem

- Boundary tracking consensus algorithms

correct, robust, distributed motion coordination


Cooperative control for distributedsensing and estimation

• Objective: systematic methodology to design and analyze cooperative strategy to control a multi-sensor system to achieve plume tracking

• Challenges:

- limited sensing/communication between sensors

- Information flow, who knows what, when, how,

dynamically changing

- How to coordinate individual sensors into a

coherent whole?


Design principles for cooperative systems

• Identification of global performance measures:

- Target Tracking

- Boundary Tracking

- Adaptive Interpolation

• Design of interaction laws:

- Rendez- vous diameter of set of neighbors

- Consensus disagreement with neighbors


Target Tracking: Source Localization

• Objective: How to place sensors/nodes/robots

p1, . . . , pn to track a moving target q0

Rendez-Vous!


Boundary Tracking: Optimal Deployment

• Example: Strictly convex bodies

• Necessary condition for optimality: optimal interpolations distribute equally the error.


Boundary Tracking

• Algorithm requirements:

- Initial estimation of boundary

- Initial positions of interpolation points

- Produce an adaptive polygonal approximation of detected boundary

• Sensors cooperatively have to: - Project & optimally place interpolation points on

boundary

- Uniformly distribute themselves according to the arc length


Future Plan


Statement of Work

• INFOD enhancement– Develop security and privacy components within INFOD– Real-time response (communication and computation)– Distributed registry

• Coordinate with other SERRI projects on its potential integration with INFOD– MSU’s emergency evacuation project

• School emergency plan system– Integrate INFOD with UT’s emergency plan system– Integrate INFOD with ORNL’s emergency plan system

• Demos– Lab demo: INFOD in plume/smoke boundary tracking– Field demo: UT and/or ORNL emergency evacuation


INFOD Security and Privacy Feature

• By May 31, 2009– Design document finished.

• June 1, 2009 - Dec. 31, 2009– Implement authentication feature within INFOD– Implement role-based access control

• Jan. 1, 2010 - Jun. 30, 2010– Adopt public-key infrastructure for authentication and validation– Integrate privacy feature into INFOD


INFOD Registry Enhancement

• By May 31, 2009– We will control both response time and CPU utilization for the INFOD

system. Previous work published in RTCSA only controls response time and so may result in poorly utilized systems.

• June 1, 2009 - Dec. 31, 2009– While our previous work was focused on a single server INFOD registry,

we plan to provide real-time response time guarantee for distributed and federated INFOD registries on multiple servers located in different places.

• Jan. 1, 2010 - Jun. 30, 2010– While our previous work addresses the response time of the INFOD

registry, we plan to address real-time communication between the INFOD registry and various subscribers, consumers, and publishers, in order to provide an end-to-end real-time information dissemination system.

– We plan to deploy and test our system in a small-scale real application environment for demonstrations.


Integration with other SERRI Projects

• University of Southern Mississippi– Evacuation from sports arena

• National Transportation Research Center (NTRC)– Redirect traffic– Oscar Frensy

• Mississippi State University– Real-time operations support for emergency evacuations– Li Zhang

• Sensorpedia– Display information gathered from sensors– Bryan Gorman ([email protected])


Integration with UT and/or ORNL Emergency Plan System

• Existing system– Can handle 3 subgroups

• New system– Code blue phones – Communication NXT

• Emergency call bridge• Reverse #1 function

• Problem– Still manual setup– A call tree


Integration with Plume Analysis

• By May 31, 2009 - We will apply the plume tracking procedure developed to different plume models.

• June 1, 2009 - Dec. 31, 2009 - Previous work focused on controlling the sensors independently. We plan

to develop distributed consensus and coordination algorithms for sensors for both plume source localization and tracking.

• Jan. 1, 2010 - Jun. 30, 2010 - Application, testing and validation of distributed sensor paradigms on

different plume models. - We plan to implement and test our system in a small scale lab experiment.


Lab Demo: Plume Tracking


Field Demo: Emergency Evacuation at Neyland Stadium


ScheduleQ2 Q3 Q4 Q1 Q2 Q3 Q4

Task 1: INFOD enhancement

Task 2: Integration of INFOD

Task 3: Lab and field demo

Task 3.2: Emergency evacuation at Neyland Stadium demo

Task 2.2: With other appropriate, feasible applications - Plume tracking

Task 1.2: Security and privacy component developmentTask 1.3: Distributed registry

Task 2.1: With other SERRI projects

Task 2.3: With UT and/or ORNL emergency plan system

Task 3.1: Lab demo: plume tracking

06/09-12/09 01/10 - 06/10Tasks

Task 1.1: Real-time response (communication and computation)

data sharing middleware prototype (dsmp) for information dissemination among heterogeneous sources

Documents