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

2. 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 tasks We assume that tasks originate from ad hoc communities of interest (CoIs) within a coalition, and that coalition members share ISR assets to some extent

3. Page 3 Agility Goal: maximize agility in sensor-mission assignment, while preserving robustness Provide as much automation as possible in the assignment of sensing assets to tasks Attempt 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

4. Page 4 Approach 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 Network Monitoring Sensor-task allocation Deployment configuration

5. Page 5 Task-Bundles-Assets T1T1 T2T2 TasksBundlesAssets A1A1 A5A5 A6A6 A4A4 A2A2 A3A3 B1B1 B4B4 B2B2 B3B3 B5B5 BT 1 BT 2

6. Page 6 An Example UK and US bases have been established to detect/deter insurgent activity on a border Surveilling the border will likely involve, among other things, detection of suspicious vehicle activity near it (T 1 ) This may be accomplished by 2 bundle types BT 1 - 1 UAV gathering IMINT BT 2 - 2 acoustic arrays gathering ACINT There are 2 UAV assets available (A 1 and A 3 ) but only one functioning IMINT payload (A 2 ) There are three acoustic arrays in the area (A 4, A 5, A 6 ) 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 (T 2 )

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

8. Page 8 Interpretation Tasks Once we have identified the interpretation tasks, we need to know the kinds of data that are interpretable to answer these An 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…

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

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

11. Page 11 A Multi-Ontology Approach A reasoner can classify according to multiple-dimensions:

12. Page 12 Semantic Matchmaking Given some task T, with required capabilities C T : Recommend a set of package configurations (PCs) of types of platforms and sensors, such that: for every capability c i in C T, there is at least one type of sensor or platform in each recommended PC that provides c i each recommended PC is minimal w.r.t. C T 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

13. 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 theatre Tasks 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 network We need a way to compute the joint utility of a particular bundle to choose the best bundle to allocate to the task

14. 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 distance The objective function is to maximize the sum of detection probabilities (weighted by task "profit" p j ), given the probability u ij that a single asset A i detects an event for T j :

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

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

17. Page 17 Coalition Use Case SAM UK SAM US Cat UK Cat US Cat Co Tasks UK Tasks US Sensor Network Config UK Config US User UK User US I2 UK I2 US

18. 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 instances The 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

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

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