Declarative Sensor Tasking Language

PIs: V.S. Subrahmanian, Larry Davis

Department of Computer Science

University of Maryland

{lsd,vs}@cs.umd.edu

1

Declarative Sensor TaskingLanguage

2V.S.Subrahmanian, Oct. 99

SenseIT Briefing

Declarative Sensor Tasking LanguageV.S.Subrahmanian and Larry Davis

University of Marylandemail: {vs,lsd}@cs.umd.edu

SenseIT objectives: Tasking and monitoring of massive sensor networks.

DoD capabilities enhanced by this project: military operations in urban terrain, real-time site monitoring and surveillance.

Scientific/technical approaches:

1. Emphasis on real-time systems

2. Declarative specification of sensor tasking.

3. Automatic triggering of actions based on real-time sensor detections.

Expected Accomplishments:1. Development of a declarative language to task sensor networks.

2. Algorithms to match task requirements against sensor capabilities and spatial/temporal/load constraints.

3. Development of Sensor Tasking Server to be used by analysts.

Start date: September 2?, 1999 Date:8/3/99


SenseIT Briefing

Motivation Thousands of diverse sensing devices, each with its own

unique hardware/software capabilities and interfaces. Analysts should not need to know every single sensor’s

capabilities in order to task the sensor.

A declarative sensor tasking language will: Allow analysts to specify (combinations of)

conditions to be monitored (what do I want to monitor?) database conditions (what background information applies?) temporal monitoring conditions (when do I want to monitor it?) geo-spatial conditions (where should this monitoring occur?)

Allow analysts to couple autonomous or event-driven actions to changes in such conditions.


SenseIT Briefing

Example Condition: Track the number of

HETs (heavy equipment transports) moving in and out of nuclear site S (region) during the next 4 weeks (time).

Action: Notify OPS1 and OPS2 if more than 25% activity (above average) is noticed on a particular day.

Action: If the activity on each day of a given week falls below 50% of the average, drop the surveillance.


SenseIT Briefing

Example Features The analyst doesn’t specifically say a particular sensor

should do the job. The system automatically assigns one or more sensors, based on matching sensor capabilities and availability with the request’s needs.

The analyst doesn’t know the individual details of each sensor. S/he merely declaratively specifies the desired conditions to be tracked.

The analyst doesn’t need to continuously track what the sensor is reporting. The system can automatically take actions when needed (if this is ok with the analyst!) -sending messages, requesting more sensors, abort,etc.

Analyst determines what gets done. System supports it.


SenseIT Briefing

IMPACT: Interactive Maryland Platform for Agents Collaborating Together

Legacy/SpecialData Structures

(distributed) data- agent state

Function CallsConcurr’cy

MSG Box

AgentProgram

Otheragents

Actions

NETWORK

Action Constraints

Integrity Constraints


SenseIT Briefing

IMPACT Overview Agent development environment and Roost provides

components for building and testing communities of IMPACT agents Java class library made of three functional groups

– agent core classes for agent definition– development class for development and testing interfaces– Roost class defines communication and control layer for

Agent communities Library file is approximately 1 Megabyte

– but Java 1.2 runtime library (6+ MB) needed on the target platform


SenseIT Briefing

Upcoming Beta release of IMPACT Globalize the potential agent community via an extended

communication layer customized Jini protocals that expand library footprint

Addition of caching and multi-query optimization techniques

Enhanced error handling and correction methods


SenseIT Briefing

What is an agent? An IMPACT agent consists of:

a set of data types a set of API functions implemented in any language

manipulating those types a set of actions implemented in any language a notion of concurrency a set of action constraints a set of integrity constraints an agent program

10

V.S.Subrahmanian, Oct. 99 SenseIT Briefing

Agent Program Set of rules of the formOp a(arg1,…,argn) <= <code call condition> &

+/- Op1 a1(<args>) & … & +/- Opn an(<args>).

Op is a “deontic modality” and is either P - permitted O - obligatory Do - do F - forbidden W - obligation is waived.

If the code call condition is true and the deontic modalities in the rule body are true, then Op a(arg1,…,argn) is true.

11


Example agent program rulesDo send-warning(E,M) <= in(Loc,entity:curloc(E)) &

in(E’,entity:hostiles()) &

in(Loc’,entity:curloc(E’)) &

in(D,geo:dist(Loc,Loc’)) &

<(D,25) &

=(M,file:create(E’,Loc’,D)).

Do log(E,M,T) <= Do send-warning(E,M) &

in(T,clock:now()) &

~ F logging.

Send a warning to entity E if there is a hostile entity within 25 distance units of it.

If a warning is sent and logging is not forbidden, then send a log message now.

12


Agent Actions An action consists of:

action name (a1,...,an) a precondition code call cond. An add list code call cond. A delete list code call cond. An execution algorithm

Actions are implemented via imperative code. Preconditions/Add/Delete lists are used by IMPACT to

assess effects of the action, not to implement the actions. Each agent has a set of associated actions. Examples of actions:

execute request modify request and execute

13


Agent action constraints Action constraints specify conditions under which the

agent cannot concurrently execute certain actions. They have the form

{a1,…,an} <~ <code call condition> This says that if the code call condition is true w.r.t. the

agent’s current state, then actions a1,…,an cannot be executed concurrently.

Examples: Moves in two different directions cannot be concurrently executed.

{ move(Dir1),move(Dir2)} <~ Dir1 <> Dir2.

Orders must stay within the budget.

{ order(Item1,Cost1),order(Item2,Cost2)} <~ in(Amt,budget:avail()) & Amt < Cost1 + Cost2.

14


Agent Integrity Constraints An agent integrity constraint is a condition that the

agent’s state must always satisfy. An agent integrity constraint has the form

<code call condition> ==> <code call atom> If the agent state satisfies the code call condition, then it

must also satisfy the code call atom. All created routes must be over 90% safe.

In(R,route:plan(Map,X1,Y1,X2,Y2)) => In(S,route:safe(R)) & S > 0.9 Everybody makes less money than their boss.

In(T1,oracle:all(‘emp’)) & in(T2,oracle:select(‘emp’,name,=,T1.boss)) => T1.sal < T2.sal

15


Agentization Procedure To convert a program to an agent, do the following:

describe types manipulated by program describe I/O types of API function calls define agent’s integrity constraints select/define actions that can be executed by agent select/define concurrency notion define agent’s action constraints define agent’s agent program

In addition, one may specify yellow pages info and register agent with IMPACT

Server specify connect information

16


Implementation Plan Capability library Algorithms to evaluate conditions across multiple sensors. Specification coupling changes in conditions to actions Tasking interface. Task Expansion Methods linking high level tasks to low level APIs. Task Planning Algorithms that create a plan to service complex

monitoring conditions. Action library to be triggered

17


Declarative Tasking Language Three sub-languages, all hidden from the analyst. What do I want to monitor? Specified in language QO

that specifies the set of objects (e.g. HETs) to be monitored.

When and where should this occur? Specified in language QST that specifies a spatio-temporal region.

What actions should be taken and under what conditions? Specified in a spatio-temporal rule based language (amenable to uncertainty/probabilistic future extensions). Specified in language STAQ (spatio-temporal-action-queries).

18


Example Queries QO can be any declarative language that takes as input

a query, and returns as output, a set of objects. Examples: SQL, Datalog, Information Integration

languages like HERMES.

SELECT vehicle

FROM collection-data C

WHERE veh-type=“HET” AND veh-activity=“unload”.

In(O,surv:select(vehicle)) &

=(O.activity,”unload”) &

=(O.veh-type,”HET”) &

in(O.mark,intel:select(‘fronts”)).

19


QST Language Examples {E: in(E,geo:entrance(site-S))}. Find all E such that E is

an entrance to site S. {P:in(P,geo:range(site-S,50,meters))}. Find all points

within 50 meters of site S. {P: in(P,geo:range(site-S,50,meters)) &

in(L,geo:location(target-vehicle)) & in(P,geo:range(L,50,meters))}. Find all points within 50 meters of site S and within 50 units of the target vehicle’s current location.

20


STAQ Language Examples In(O,surv:select(vehicle)) & =(O.activity,unload) &

in(O.objects,crate) ==> monitor(O,6) & create(report,O,R,2) & email(john,R,2) & email(lynn,R,4).

If an object O currently being surveyed is unloading a crate, then: monitor O with priority level 6, and create a report R about O with priority level 2, and email this report to John with priority 2 and to Lynn with priority 4.

Rules are of the form: “If condition then execute a prioritized set of actions”.

21


GUIDisplay

Message Handling

Network Routing

Sensors

DM DMDMDMDM

MobileCode

DeviceStatus

Detection/Classification

TimeSeries

HighLevel

Sensor taskingand monitoring

22


Leveraging Proposed effort builds on top of three previous efforts:

HERMES Heterogeneous Reasoning and Mediator System for information integration funded by DARPA I3.

IMPACT Interactive Maryland Platform for Agents Collaborating Together platform for creating and deploying multiagent applications funded by ARL and DARPA CoABS.

Work on temporal-probabilistic databases partly funded by Lockheed Martin.

23


Architecture Details The Tasking and Monitoring Component being designed by us will

fit into the BBN Architecture as follows: Users may connect to the Task Manager via any Java compliant web

browser. The Task Manager interfaces allows the user to specify his monitoring

needs– what to monitor– what to do when certain monitoring conditions are detected

The Task Manager examines the current state:– where are the sensors now?– what are they doing?

Based on this and the capabilities of the sensors, it creates a “task plan” that optimizes an objective function.

A task plan relays monitoring instructions to the sensors and develops methods to merge the results returned.

24


Leveraging Proposed effort builds on top of three previous efforts:

HERMES Heterogeneous Reasoning and Mediator System for information integration funded by DARPA I3.

IMPACT Interactive Maryland Platform for Agents Collaborating Together platform for creating and deploying multiagent applications funded by ARL and DARPA CoABS.

Work on temporal-probabilistic databases partly funded by Lockheed Martin.

25


Contact Information

V.S.Subrahmanian

Dept. of Computer Science

University of Maryland

College Park, MD 20742.

EMAIL: [email protected]

TEL: (301) 405-2711

FAX: (301) 405-8488

URL: www.cs.umd.edu/users/vs/index.html

Documents

Declarative Sensor Tasking Language