reasoning and resource allocation for sensor- mission assignment in a coalition context a. preece,...
Post on 27-Mar-2015
214 Views
Preview:
TRANSCRIPT
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)
Page 2
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
Page 3
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
Page 4
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
Page 5
Task-Bundles-Assets
T1
T2
Tasks Bundles Assets
A1
A5
A6
A4
A2
A3
B1
B4
B2
B3
B5
BT1
BT2
Page 6
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)
Page 7
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
Page 8
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…
Page 9
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
Page 10
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”
Page 11
A Multi-Ontology Approach
A reasoner can classify according to multiple-dimensions:
Page 12
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
Page 13
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
Page 14
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:
Page 15
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
Page 16
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:
Page 17
Coalition Use Case
SAMUK SAMUS
CatUK CatUS
CatCo
TasksUK TasksUS
Sensor Network
ConfigUK ConfigUS
UserUK UserUS
I2UK I2US
Page 18
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
Page 19
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
Page 20
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?
top related