Guidance

Autonomous sensor management and sensor counter deception - Frequently Asked Questions

Updated 17 August 2023

0.1 Q: What is the scope for “autonomous sensor management” problem space? The algorithmic development can be quite closely coupled with the problem space.

A: The scope is broad, defence relevant scenarios are of interest. If you have a particular area of application you think we would be interested in we would welcome the submission. In terms of the algorithm development being closely coupled with the solution, the framework that we’d like to build this into is trying to keep things as generic as possible although the approach that you’re building is specific to a scenario we would hope that the components are as general as possible and it’s the interoperability and ability to evaluate against different objectives. It wouldn’t be a disadvantage to specific in your scenario. Refer to the programme remit. This is looking at generation after next, consciously looking at information theory rather than specific systems. This requires a more general approach. General purpose methods will be applicable across multiple platforms.

0.2 Q: All sensors have an evolution for a SwaP capability so any agnostic SW [software] it will need some process to evolve that too?

A: SwaP is a concern and addresses the scalability issue and the requirement to be deployed on future systems. It will be useful to consider SwaP.

0.3 Q: Our nUAS which has EO IR and 3d depth fusion, and payload sensor disrupt or disorientate and collect ISR our AI engine SW [software] not Stone soup. Can we still enter this competition?

A: Yes. Stone Soup is not a hard requirement but it is a strong preference because it allows us to do fair assessment and rapidly incorporate algorithms in to our own projects and programmes. Yes you can still enter but we would encourage you to look at Stone Soup as you may be able to find ways of using this even if it’s just as a test environment. Clarification that the call is more interested in algorithms rather than physical implementation.

0.4 Q: Re: Challenge 1, would new (low TRL) algorithms which could be integrated/demonstrated with a higher TRL system be of interest?

A: Low TRL algorithms are of interest, Phase 1 projects are expected to deliver outputs at TRL 3. High TRL is of interest too, we would prefer to keep the approach general

0.5 Q: Challenge 1: Given there is a lot of high TRL work already underway in relation to detect, track, identify; what research deltas are considered in this call?

A: Key part is to develop general solutions that can be applied to multiple/any sensors and a framework approach where we can trade in different types of sensors and potentially different types of reward policies or balance different types of rewards. There is lots of academic research out there on this which is less applied. This is a route to build this into a research framework and, in future applied scenarios.

0.6 Q: Challenge 1: What type of sensors (to be managed) are of higher priority?

A: This is up to you, whatever you’d like to focus on. Options are open to whatever you’d like to contribute. We consider sensors to be abstract things which return data to answer ISR questions. We can apply algorithms to any sensors, including those that haven’t been created yet. We’re not interested in a specific sensor. A higher priority will be sensors that are likely to fit into future sensing systems.

0.7 Q: If you are trying to apply the SW [software] from a Nano UAS to large sensors in another platform, will this be difficult?

A: Potentially. There is always the possibility that your algorithm isn’t going to work as well in a different scenario, but the key is whether it’s applicable. The framework we have allows for interoperability between modules of your programme. We are interested in seeing difficult aspects tackled in this competition.

0.8 Q: Is ‘orientation’ a separate consideration to location or movement in this context?

A: This depends on your sensor. If you have a senor with a field of view that’s impacted by orienting it and then moving it then they are two separate things; consider the combination of those changes. If orientation doesn’t impact the information that you’ll get back from that sensor then it’s probably less relevant and similar to movement and could combine into one thing. It’s all about the information you’d be getting from the sensor and whether the action (sensor tasking) would change that.

0.9 Q: Would the detection of spoofing of signals that are primarily in use in civilian domain, e.g. AIS or ADS-B be potentially within scope?

A: Yes

0.10 Q: So if you are looking at information theory rather than sensor specific, is this challenge more aimed at academia not industry?

A: There is no preferred sector

0.11 Q: Would planning and mission task optimisation algorithms be seen as applicable to challenge 1

A: Yes, potentially. Wouldn’t want it to be specific to a certain mission scenario. We would be interested in the particular algorithm and how it could be applied and flexed to other scenarios.

0.12 Q: in the realms of CUAS I see remote ID playing a part in this area. Are you engaged with the CAA in understanding / influencing this upcoming development?

A: Not within this project but within wider Dstl.

0.13 Q: Is there any public documentation of the SAPIENT->Stone Soup integration? Searching for SAPIENT in https://stonesoup.readthedocs.io/ returns 0 results

A: Not available yet, this is currently in development.

0.14 Q: Does Stone Soup already have an interface for (multi-agent) reinforcement learning?

A: We have a reinforcement learning example for sensor management which was developed by University of Liverpool. This is a good example of one way of incorporating reinforcement learning but it isn’t the only way it can be done. Other approaches could be developed depending on what you’re trying do.

0.15 Q: So Stone Soup is open environment under MIT that hopefully interfaces to the core?

A: There’s lots of ways to interface. Can be right down at the component level of having different distance measure or right up to the high level of data at one end, tracks at the other end and everything inside is a black box. You might want to just use Stone Soup to help with simulation and metricating when assessing performance. Or you might want to build a component that slots in a specific reward function for your sensor management, so various different levels at which you can interface.

0.16 Q: how is Stone Soup provided and under what licence type?

A: Stone Soup core is under MIT licence, a permissive licence which means you can use it as you wish. There’s no copy left. You can add in plug-ins, components that interface that be proprietary, under different licences, classified etc. The idea is that if it’s compatible with the framework then we can rapidly use it and apply to different problems that we have but it doesn’t mean that it has to be open source.

0.17 Q: If Stone Soup just a test environmental process, what is the process for our AI and sensors fusion to link to this SW [software] application set?

A: Stone Soup is aimed at research framework for assessing things, not something that would be operationally deployed. You can plug sensors into it with some caveats around running in real time. Depend what it is that you are trying to link; take a look to see if can be built to be compatible.

0.18 Q: Is it imperative that we meet the company requirements/criteria for DASA before pitching an idea? For example registration with Companies House for e.g. in terms of TRL?

A: This depends on which part of the DASA offer you are interested in. Open call and Themed are generally open to any company, right down to a sole trader so please discuss with your innovation partner. There are more requirements for DTEP and our Defence Innovation Loans. We don’t assess from pitch, it will be through application form. There are no requirements to speak to an Innovation Partner for our open and themed competitions but it is strongly advised.

0.19 Q: We’re a bit concerned about Open Sourcing our code, especially our background IP which is patented. Will it be admissible to use extensions that hide the code?

For this competition, DASA wishes to secure the ability to open source code/algorithms generated under the competition (foreground IP), as necessary, especially if they are to become a part of Stone Soup. This is not a change in policy from DASA, but a specific requirement for this competition.

For this purpose, DASA requests delivery under the Apache 2.0 licence, in addition to Defcon 705. Referencing the competition document: “all code/algorithms generated under this competition must be delivered under both the IP condition Defcon 705 and under the Apache 2.0 licence, which thereby permits publication and making available open source.”

This only includes foreground IP generated under this competition and does not impact any background IP which belongs to the supplier.

If deliverable information/code/algorithms is likely to include background IP, then this should be highlighted to DASA as part of the submission process, indicating how this is likely to impact on DASA’s desired rights of use. DASA can then consider this as part of its assessment.

The default delivery mechanism for code will be to a closed Dstl repository. This allows Dstl to store algorithms internally, still have them compatible with Stone Soup and therefore useful to Dstl for research purposes. The Apache 2.0 license gives Dstl the rights to decide if these algorithms should then be open sourced. However, the project and technical partner will work with the supplier to determine which algorithms would be appropriate or useful to open source.

Motivation for open sourcing code includes (but is not limited to) providing components to enable further algorithmic development, as well as building capability in the Stone Soup and wider academic communities. This is achieved by sharing algorithms which are generally applicable and useful to others.

There are a number of reasons we may wish to keep something internal – for example if the use case is too sensitive or if there is novel work that it would be advantageous to keep out of the public domain. If the supplier believes there are parts of the work which should not be open sourced for a particular reason, then it should be highlighted clearly in the proposal but understood that the decision will be made by Dstl.

0.20 Q: DASA weights scoring towards exploitation. If you want everything open source, how can we demonstrate exploitation of our own research?

A: DASA scores submissions over three areas: desirability, feasibility and viability. Regarding exploitation, you may wish to consider where your innovation could be used across defence(and indeed the civil sector), which is relevant to exploitation irrespective of whether DASA may decide to open source some solutions, such as through Stone Soup.

0.21 Q: Are the challenges assessed jointly or separately? Can one proposal address both challenges?

A: DASA process is that a minimum of three assessors with relevant expertise are assigned to each proposal. Each proposal is assessed individually. Proposals can address more than one challenge but we would discourage a proposal that covers two entirely separate things. Multiple submissions are permitted.

0.22 Q: Is there sufficient time to get feedback on Innovation Outlines?

A: This would depend on when you submit an outline of the idea. Speak to your regional innovation partner. They can look at the applicability of your innovation to the competition. If they’re unsure they may ask you to submit some details to run by the competition team to give an indication of whether your idea is in scope. This won’t give any detailed direction. Make contact in good time.

0.23 Q: What is the view on industry driving scope of some of the proposals (rather than bidding themselves) as an earlier intervention to drive exploitability in specific domains?

A: You can collaborate on a proposal. Include in your proposal what each collaborator will be doing.

Within DASA we have strategic partners that cover the strategic suppliers to defence, if you’re thinking of the higher level strategic direction (and sit within one of the strategic suppliers to defence) we would recommend you connect to them via your regional innovation partner.

0.24 Q: A question relating to international collaboration, is this allowed? I have previously worked on this topic in Australia (DSTG) so could be beneficial

A: Yes, international collaborations are welcome It would have to be a commercial organisation. If it’s of interest to DSTG also, this could be cited within the “Desirability” criteria, but the proposal would still need to relate to this competition and UK Dstl requirements.

0.25 Q: What is the name of the paper that attempts to quantify deception referenced in the briefing?

Two papers were referenced in the briefing:

Whaley, B. 1982, Toward a general theory of deception, Journal of Strategic Studies, 5:1, 178-192, DOI: 10.1080/01402398208437106

Barr et al. 2023, Toward a General Theory of Sensor Deception, in Proceedings of the 10th NATO Military Sensing Symposium, MP-SET-311-101 or MP-SET-311-C13.

DASA cannot supply the latter, but it can be made available to eligible parties via NATO Science and Technology Organisation. Please note this is only background information and not required for an application.

0.26 Q: What is the timeline you are working to for submission date and start date please?

A: The competition closes on 13th September. We will aim to start contracting in November and end 12 months later, completing no later than February 2025.