Reasoning and Resource Allocation for Sensor- Mission Assignment in a Coalition Context A. Preece,...

Reasoning and Resource Allocation for Sensor-Mission Assignment in a Coalition Context

A. Preece, D. Pizzocaro, K. Borowiecki (Cardiff University, UK)G. de Mel, M. Gomez, W. Vasconcelos (University of Aberdeen, UK)A. Bar-Noy, M.P. Johnson (CUNY, US)T. La Porta, H. Rowaihy (Penn State University, US)G. Pearson (DSTL, UK)T. Pham (ARL, US)

Sensor-Mission Assignment

Dynamic, mission-focussed intelligence, surveillance and reconnaisance (ISR) requires agile management of information-provisioning capabilities

rapid assembly of sensing systems efficient resource management ability to (re)configure & (re)task

Sensor-mission assignment: allocate a collection of ISR assets to a set of tasks, in an attempt to satisfy the ISR requirements of those tasksWe assume that tasks originate from ad hoc communities of interest (CoIs) within a coalition, and that coalition members share ISR assets to some extent

Agility

Goal: maximize agility in sensor-mission assignment, while preserving robustnessProvide as much automation as possible in the assignment of sensing assets to tasksAttempt to capture information requirements of CoIs in a manner independent of the capabilities of asset types

to allow multiple degrees of freedom in allocation and reallocation of assets

We deal with heterogeneous task and sensor types, and there is a many-to-many relationship between these:

the same kind of task can be accomplished in several different ways; the same type of asset can serve many different kinds of tasks

This enables flexibility at planning time, and also at run-time

ApproachQuickTime™ and a

TIFF (Uncompressed) decompressorare needed to see this picture.

Requirements• Define IREQs & SSIRs• Derive interpretation tasks Sensor-task

fitting

Logistical information• sensor/platform type• location• readiness

Recommendation of fit-for-purpose types of ISR solutions

Status updating

Mission planning

ISR assets available in theatre

Information delivery

S1

S2

S3

DB

C

E

A

S4

Sensor NetworkMonitoring

Sensor-task allocation

Deployment configuration

Task-Bundles-Assets

T1

T2

Tasks Bundles Assets

A1

A5

A6

A4

A2

A3

B1

B4

B2

B3

B5

BT1

BT2

An Example

UK and US bases have been established to detect/deter insurgent activity on a borderSurveilling the border will likely involve, among other things, detection of suspicious vehicle activity near it (T1)This may be accomplished by 2 bundle types

BT1 - 1 UAV gathering IMINT BT2 - 2 acoustic arrays gathering ACINT

There are 2 UAV assets available (A1 and A3) but only one functioning IMINT payload (A2)

There are three acoustic arrays in the area (A4, A5, A6)There will be other tasks in competition for these assets, e.g. a requirement to detect vehicles posing a potential threat to the bases’ supply route (T2)

Specifying Tasks

High-level information requirements are defined informally, using natural language. For example: "Is there suspicious activity on the main supply road?"Each high-level IREQ must be broken down into a set of scenario-specific information requirements:

Are there suspicious vehicles on the road? Is there suspicious pedestrian activity along the roadside? Are there suspicious objects located near the road?

The SSIRs need to be broken down further before they can be matched to types of ISR asset, in order to identify the interpretation tasks within each:

detect vehicles where vehicle type or behavior is suspicious detect people where person type or behavior is suspicious detect object where object type is suspicious

Interpretation Tasks

Once we have identified the interpretation tasks, we need to know the kinds of data that are interpretable to answer theseAn established way to do this in CCIRM is to use the NIIRS scale for various kinds of imagery intelligence.

e.g. detection of vehicles of particular types is achievable by Visible NIIRS 4 and Radar NIIRS 6

Our NIIRS KB allows a user to select interpretation tasks in terms of three types (detect, identify, distinguish) and a range of detectables

the KB infers which NIIRS ratings are appropriate for each task

Thus we move from a set of “soft” information requirements to a set of “hard” (machine-processable) requirements It is also necessary to identify “non-functional” requirements at this stage…

Sensor-Task Fitting

Founded on the use of ontologies to represent the capabilities required by tasks and provided by assets, and reasoning to determine logically-sound matches

Ontologies define formally the semantics of a set of terms, allowing automatic reasoning to be performed using the terms

There is already a sizeable amount of work in providing descriptive schemas and ontologies for

sensors, sensor platforms, and their properties tasks in the military missions context

Ontologies allow the results of the fitting process to be explainable in meaningful terms

An Example

Examples of how to read these definitions: “a UAV is an Aircraft and an UnmannedVehicle” “a CombatUAV is a UAV and something that

providesCapability Firepower”

A Multi-Ontology Approach

A reasoner can classify according to multiple-dimensions:

Semantic Matchmaking

Given some task T, with required capabilities CT: Recommend a set of package configurations (PCs) of types of platforms and sensors, such that:

for every capability ci in CT, there is at least one type of sensor or platform in each recommended PC that provides ci

each recommended PC is minimal w.r.t. CT

A PC could be: a single platform+sensor arbitrarily complex with many types of platform, each mounting a

variety of sensor types

Note that the matching procedure works with sensor and platform types - benefits from optimised subsumption-based reasoners

Allocating Asset Instances

Aim: find an optimal allocation of individual asset instances to tasks while ensuring that they are correctly grouped into bundles (instantiation of bundle types)Allows us to factor in logistical information (location, cost, readiness, etc) related to particular asset instances available in theatreTasks might compete for the exclusive usage of the same asset instance goal is to allocate specific assets to the tasks in order to

maximize the utility of the sensor networkWe need a way to compute the joint utility of a particular bundle to choose the best bundle to allocate to the task

CDP Maximisation

Each task can be classified according to task type The task/bundle types determine the joint utility model In our example we have two event detection tasks for which a JUM is Cumulative Detection Probability (CDP)The utility of a sensor asset to a task is the probability that it will successfully detect the event if it occurs (we assume there are no false positives), which might be based on distanceThe objective function is to maximize the sum of detection probabilities (weighted by task "profit" pj), given the probability uij that a single asset Ai detects an event for Tj:

Protocol for Event Detection

To solve this problem, we propose a distributed bidding protocol where sensor assets bid for tasksA distributed approach does not require any central node to make the allocation decisionsThis allows the protocol to leverage run-time status information about assets which are operational and which may currently be assigned to other tasks

Pilot Application

We have implemented a pilot application called SAM (Sensor Assignment to Missions) as a proof-of-concept to test and refine our approach:

Coalition Use Case

SAMUK SAMUS

CatUK CatUS

CatCo

TasksUK TasksUS

Sensor Network

ConfigUK ConfigUS

UserUK UserUS

I2UK I2US

Evaluation

The SAM tool has been demonstrated to stakeholders in the UK MoD and US ARL, with positive feedback

the ability of the tool to generate explanations and support “what-if” explorations of potentially-available ISR solutions

incorporation of various kinds of policy (e.g. restricted “advertising” of assets within the coalition)

The fitting alg is exp-time and the allocation alg is poly-time; but there will usually be far fewer asset types than instancesThe task-bundle-asset model provides two degrees-of-freedom in allocating and reallocating assets to tasks

at planning time, a range of options is identified for each task by the fitting algorithm

choose an alternative task-bundle pairing at run-time without incurring the cost of re-running the fitting reasoning

Discussion & Conclusion

Our work takes a deliberately simple approach to resource scheduling

we envisage the allocation algorithms being run dynamically at discrete timesteps throughout operations

we accept that resource scheduling approaches may be beneficial

We assume that an asset is assigned exclusively to one bundle, and a bundle is assigned exclusively to one task

we intend to relax this restriction in future work, to allow sharing of bundles among tasks, and assets among bundles

Use of the bundle formalism allows us potentially to cope with three additional important aspects of CCIRM:

assignment of complementary sensing types to the same task assignment of assets other than sensors and platforms sensor cueing

Acknowledgements

This research was sponsored by the US Army Research Laboratory and the UK Ministry of Defence and was accomplished under agreement W911NF-06-3-0001. The views contained in this paper are those of the authors and should not be interpreted as representing the official policies, either expressed or implied, of the US ARL, the UK MoD, or the US or UK Governments. The US and UK Governments are authorized to reproduce and distribute reprints for Government purposes notwithstanding any copyright notation hereon.

Thanks for listening!

Any questions?

Reasoning and Resource Allocation for Sensor- Mission Assignment in a Coalition Context A. Preece,...

Documents

Transcript of Reasoning and Resource Allocation for Sensor- Mission Assignment in a Coalition Context A. Preece,...