Declarative Sensor Tasking Language

1. Declarative Sensor TaskingLanguage PIs: V.S. Subrahmanian, Larry Davis Department of Computer Science University of Maryland {lsd,vs}@cs.umd.edu 1

2. Declarative Sensor Tasking LanguageV.S.Subrahmanian and Larry Davis University of Marylandemail: {vs,lsd}@cs.umd.edu Start date: September 2?, 1999 Date:8/3/99 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.

3. 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.

4. 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.

5. 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.

6. Agent Program Actions Concurr’cy Function Calls MSG Box Legacy/Special Data Structures Action Constraints Integrity Constraints Other agents (distributed) data - agent state NETWORK IMPACT: Interactive Maryland Platform for Agents Collaborating Together

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

8. 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

9. 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. Agent Program • Set of rules of the form Op 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 rules Do 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 a(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. In(O,surv:select(vehicle)) & =(O.activity,”unload”) & =(O.veh-type,”HET”) & in(O.mark,intel:select(‘fronts”)). SELECT vehicle FROM collection-data C WHERE veh-type=“HET” AND veh-activity=“unload”.

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. DM DM DM DM DM GUI Display Sensor tasking and monitoring Mobile Code Device Status Time Series Detection/ Classification High Level Message Handling Network Routing Sensors

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: vs@cs.umd.edu TEL: (301) 405-2711 FAX: (301) 405-8488 URL: www.cs.umd.edu/users/vs/index.html