Guidance

Autonomous sensor management and sensor counter deception: Competition Document

Updated 17 August 2023

1. Introduction

This Defence and Security Accelerator (DASA) competition is funded by the Defence Science and Technology Laboratory (Dstl). It seeks proposals that develop solutions for autonomous sensor management and sensor counter deception in intelligence, surveillance and reconnaissance (ISR) scenarios.

Autonomous sensor management is the process of deciding and executing the actions that a group of sensors should take in a given scenario to complete a particular ISR task. In the defence context, such objectives may include target tracking, target classification and developing/maintaining situational awareness. In a world of increasing complexity in terms of the number of sensors and capability, there is a need for algorithms which will process information and disseminate instructions to address ISR queries at human or beyond human-tempo.

Full-spectrum, pervasive ISR is one of the Ministry of Defence’s (MOD) five key capability challenges as outlined in the Science and Technology Strategy. To realise the ambition of tackling ISR challenges at scale and at pace, it is vital to achieve a high degree of autonomy in the processes that underpin the ISR enterprise. This environment will be most-often contested with picture compilation schemes which rely on passive situations, which are of limited utility.

Methods which help detect and counter activities designed to deceive the ISR picture are crucial. This is important, not only because adversaries inherently hide their intent and will project false intent, but also because defence scenarios are nearly unique in this respect. Therefore, drawing across techniques from more benign or cooperative situations has limited utility. Techniques must be developed which have the accommodation for potentially deceptive activity built-in.

This competition is part of the Sensor Fusion and Management (SFM) project which leads on generation-after-next sensor fusion and management research. The project sits under Dstl’s Future Sensing programme and the research generated feeds into the “Sensing” defence S&T capability.

2. Competition key information

2.1 Submission deadline

Midday on Wednesday 13 September 2023 (BST).

2.2 Where do I submit my proposal?

Via the DASA Online Submission Service for which you will require an account. Only proposals submitted through the DASA Online Submission Service will be accepted.

2.3 Total funding available

The total possible funding available for Phase 1 of this competition is £800,000 (excluding VAT).

This competition is looking to fund 6-12 proposals.

Additional funding for further phases to increase TRL may be available. Any future phase, will be open to applications from all innovators and not just those that submitted Phase 1 successful bids.

3. Supporting events

On 20 July 2023, DASA hosted a webinar providing further detail on the competition’s challenge areas. Watch the webinar below.

Autonomous Sensor Management and Sensor Counter Deception: Webinar

4. Competition Scope

4.1 Background:

It is key for military personnel to be able to establish and maintain sufficient understanding of the current and potential tactical, operational and strategic environment to enable sound decision making. Such situational awareness relies on good intelligence, surveillance and reconnaissance (ISR). ISR processes are often human-centric; from collection planning and analysis of processed single sensor data, to the presentation of information, which can have non-desirable effects such as high cognitive burden on users, extended time to produce information and missed opportunities to discover important information. In military scenarios, the ISR picture is further complicated as the intent of the targets in the environment is not always clear, and may be deliberately hidden or misrepresented.

The Sensor Fusion and Management (SFM) project under Dstl’s Future Sensing programme is leading on generation-after-next sensor fusion and management research. Two themes that the projects addresses is methods to enable autonomous sensor management (allowing reactive ISR) and techniques for detecting and mitigating deceptive activities when compiling and using an ISR picture. Other themes include data fusion and architectural approaches to fusion in distributed networks and enterprises. This includes development work on the SAPIENT sensor integration standard and concept.

Dstl’s principal evaluation and testing route for novel algorithms of this type is via Stone Soup. Stone Soup is an open source software framework for the assessment of tracking and state estimation algorithms. This framework is built in a modular way using an object-oriented approach, enabling construction of sophisticated algorithms from lower-level components. The modularity also enables the same components to be applied to many different domains, targets, sensor modalities, and fusion architectures. Crucially, assessments can be made of different algorithms against representative and consistent simulated, recorded, or live data by using the metrics available in the framework. The Stone Soup source code is available on GitHub and its documentation is available on readthedocs.org.

5. Scope

5.1 This competition seeks:

• novel algorithms for autonomous sensor management and sensor counter deception for future ISR systems
• new ideas and contributions to the SFM project via the Stone Soup framework
• to build our community of users and developers by working with a diverse range of external partners.

This competition is interested in supporting innovation at low Technology Readiness Level (TRL). It is expected that Phase 1 projects will deliver outputs at TRL 3.

We require solutions to be delivered in a form which can integrate within a broader set of signal and information fusion technology demonstrators, particularly the algorithms available in the Stone Soup framework. We require open, flexible, and modular architectures to enable integration.

Algorithms should be written in object oriented Python, as components which are compatible and could be merged into the Stone Soup framework. It should be noted that Stone Soup is designed for the assessment of algorithms, and as such, is aimed at a research-level of code and performance, with tests and documentation for simple scenarios; it is not aimed at operational or real-time use. If changes to existing parts of the framework are required, this is acceptable and notes should be made on any breaking changes. The output should provide all the components to run the given algorithm with all new code covered by unit and integration tests. Documentation should also be provided for any new components created. Guidance on code style, testing and documentation can be found on the documentation pages.

Please note, Dstl not only wishes to share algorithms/code generated under this competition with the broader defence community, but also wishes to secure the rights to publish/open-source any algorithm and code generated. Consequently, 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. Please see the terms for this competition, here for further details.

6. Competition Challenges

This competition has two challenges.

6.1 Challenge 1: Sensor Management

Sensor management is the process of deciding and executing the actions that a sensor or group of sensors will take in order to meet a particular objective. Objectives could include searching for objects of interest, target detection, identification, recognition, tracking or improved situational awareness among many others, including complex multi-objective problems. For example, an uncrewed aerial vehicle may be required to observe an area to find and track objects of interest. The actions required to search for targets are quite different to those required to track, and so competing objectives will have to be balanced.

The actions a sensor could take encompass tasks such as pointing direction, field of view, beam pattern, sensitivity, power status etc. The tasking of sensor location is also of interest, primarily as a dynamic problem where a sensor can be moved during a scenario (e.g. it is attached to a platform such as an uncrewed vehicle), but also in terms of optimising static sensor placement.

Sensor management algorithms are well explored in academic literature, but difficult to implement due to the practicalities of the problem (i.e. large sets of possible actions to optimise over). This means the autonomous sensor management methods applied to real scenarios are still largely heuristic, with humans anticipating new targets and applying context. This is suboptimal and unsustainable in scenarios of increasing complexity and autonomy.

Initial work has been done to experiment with sensor management approaches using the Stone Soup framework. Simple enactments of sensor management are available on the documentation site.

In the first instance, additional sensor management capabilities are required which are compatible with Stone Soup and this existing setup. The second key element of this request is to demonstrate autonomous sensor management by applying the algorithm(s) implemented in simulation. A scenario should centre on a specific objective (or objectives), with sensor actions selected in order to maximise some reward (or minimise cost).

Possible component developments could include:

• reward functions
• cost functions
• sensor management policies
• optimisation approaches
• “taskable” sensor models

Research areas that might help solve this challenge area may include but are not limited to:

• information theory
• game theory
• reinforcement learning

6.2 Challenge 2: Sensor Counter Deception

Military sensing is often complicated by the fact that an adversary’s objective is in direct conflict with one’s own. Adversaries will therefore work hard to obscure their intent, for example by hiding, manipulating their signature or deploying decoys and countermeasures. This complicates inference and means any useful ISR picture compilation must be robust to this activity. Furthermore, behaviour like this is not confined to a single domain or single sensor modality. Techniques found in certain scenarios have analogues in others (e.g. radar jamming/optical dazzle).

The SFM project, under a mandate to improve ISR picture compilation, looks to develop and demonstrate methods to counter sensor deception. Furthermore, it seeks to develop techniques to enable an understanding of the impact deceptive strategies have on a situational awareness picture. Impacts may range from an increase in uncertainty, to attempts to inculcate a false conclusion, or promote a decision conducive to the deceiver. Solutions should employ a defined and recognised set of ISR metrics, an example of which can be found here to quantify the impact of sensor deception, as well as delivering strategies to mitigate such deception. Solutions should be Stone Soup compatible and should allow Dstl to derive and compare metrics which quantify the effect of a range of deceptive activities. Dstl technical partners will work with the supplier to arrive at a common understanding and direct how best to deploy novel algorithms in Stone Soup.

We do not seek to be overly prescriptive as regards solutions. We are, however, looking for methods which can be engineered within future ISR and autonomous systems and will eventually deliver benefit to the intelligence community. Preference will therefore be given to research which shows strong potential for exploitation in this direction. Cross-disciplinary research is encouraged.

Ideas that might help solve this challenge area may include (but are not limited to):

• modelling of intent,
• efficient optimisation,
• game theory,
• Bayesian inference,
• scalable inference on graphs,
• high-dimensional sampling methods.

7. We are interested in…

We want novel ideas to advance research and development (R&D) in ISR for UK Defence and Security. Your proposal should include evidence of:

• alignment to at least one of the two challenge areas outlined above. This competition seeks novel solutions to the problems of autonomous sensor management and sensor deception in intelligence, surveillance and reconnaissance (ISR) scenarios

• contributions which will be delivered in object-oriented Python, compatible for integrating into the Stone Soup framework

• suppliers working with Dstl to arrive at a common understanding of how to apply the theory of autonomous sensor management and sensor counter deception, and how best to deploy novel algorithms in Stone Soup

• theoretical development, method of advancement or proof of concept research which can demonstrate potential for translation to practical demonstration in later phases

• innovation or a creative approach

• clear demonstration of how the proposed work applies to any defence and security context

8. We are not interested in…

We are not interested in proposals that:

• deliver software in proprietorial form or with restrictive constraints in the form of libraries, licences, executables, etc. which impair the ability of Dstl to evaluate and assure the deliverable

• constitute consultancy, paper-based studies or literature reviews which just summarise the existing literature without any view of future innovation (which therefore cannot be extended into Phase 2)

• are an unsolicited resubmission of a previous DASA bid

• offer demonstrations of off-the-shelf products requiring no experimental development (unless applied in a novel way to the challenge)

• offer no real long-term prospect of integration into defence and security capabilities (e.g. if they have very large computational requirements, or highly-specialised hardware)

• offer no real prospect of out-competing existing technological solutions

9. Accelerating and exploiting your innovation

It is important that over the lifetime of DASA competitions, ideas are matured and accelerated towards appropriate end-users to enhance capability. How long this takes will depend on the nature and starting point of the innovation.

Stone Soup provides the framework for implementing novel algorithms and testing and evaluating their performance. This enables the demonstration of low TRL algorithms through simulation, from which promising approaches can then be developed further.

The next steps include the potential for a Phase 2 of the competition, ending in demonstration of successful proposals with a wider objective to demonstrate to stakeholders methods of detecting and mitigating the detection of sensors. Within a Phase 2, algorithms could also be deployed on real sensors using the SFM project’s Deployable ISR Experimentation Testbed, which has a set of sensors which can be used for experimentation purposes. These sensors are SAPIENT compatible, providing potential to deploy developed technical solutions as part of a SAPIENT architecture (guidance can be found here and the interface control document here).

Suppliers should aim to deliver Phase 1 outputs at TRL3. It is envisaged that Phase 2 projects will deliver outputs at TRL 6 and demonstrate the resulting technologies to military stakeholders.

10. A clear route for exploitation

For DASA to consider routes for exploitation, ensure your deliverables are designed with the aim of making it as easy as possible for collaborators/stakeholders to identify the innovative elements of your proposal.

Whilst DASA recognises that early identification and engagement with potential end users during the competition and subsequent phases are essential to implementing an exploitation plan, during the competition phase there should be no correspondence between suppliers and DASA other than via the DASA helpdesk email at accelerator@dstl.gov.uk, or their local Innovation Partner.

All proposals to DASA should articulate the expected development in technology maturity of the potential solution over the lifetime of the contract and how this relates to improved capability against the current known (or presumed) baseline.

11. How to outline your exploitation plan

The primary exploitation route within this phase of the competition is through the Stone Soup framework but we want to understand any potential for exploitation at a higher technology maturity in future phases. Include the following information to help the assessors understand your exploitation plans to date:

• the intended defence or security users of your final product and whether you have previously engaged with them, their procurement arm or their research and development arm

• awareness of, and alignment to, any existing end user procurement programmes

• the anticipated benefits (for example, in cost, time, improved capability) that your solution will provide to the user

• whether it is likely to be a standalone product or integrated with other technologies or platforms

• expected additional work required beyond the end of the contract to develop an operationally deployable commercial product (for example, “scaling up” for manufacture, cyber security, integration with existing technologies, environmental operating conditions)

• additional future applications and wider markets for exploitation

• wider collaborations and networks you have already developed or any additional relationships you see as a requirement to support exploitation

• how your product could be tested in a representative environment in later phases

• any specific legal, ethical, commercial or regulatory considerations for exploitation

12. Is your exploitation plan long term?

Long term studies may not be able to articulate exploitation in great detail, but it should be clear that there is credible advantage to be gained from the technology development.

Include project specific information which will help exploitation. This competition is being carried out as part of a wider MOD programme and with cognisance of cross-Government initiatives. We may collaborate with organisations outside of the UK Government and this may provide the opportunity to carry out international trials and demonstrations in the future.

13. How to apply

13.1 Submission deadline

Midday on Wednesday 13 September 2023 (BST).

13.2 Where do I submit my proposal?

Via the DASA Online Submission Service for which you will be required to register.
Only proposals submitted through the DASA Online Submission Service will be accepted.

13.3 Total funding available

The total funding available for Phase 1 of this competition is £800K (excluding VAT).
Additional funding for further phases to increase TRL may be available. Any further phases will be open to applications from all innovators and not just those who successfully submitted Phase 1 bids.

13.4 For further guidance

Click here for more information on our competition process and how your proposal is assessed.

Queries should be sent to the DASA Help Centre – accelerator@dstl.gov.uk.

14. What your proposal must include

• the proposal should focus on the Phase 1 requirements but must also include a brief (uncosted) outline of the next stages of work required for commercial exploitation
• when submitting a proposal, you must complete all sections of the online form, including an appropriate level of technical information to allow assessment of the bid and a completed finances section
• completed proposals must comply with the financial rules set for this competition. The upper-limit for this competition is £800K (excluding VAT) in total to fund 6-12 proposals. Proposals will be rejected if the financial cost exceeds this capped level
• you must include a list of other current or recent government funding you may have received in this area if appropriate, making it clear how this proposal differs
• a project plan with clear milestones and deliverables must be provided. Deliverables must be well defined and designed to provide evidence of progress against the project plan and the end-point for this phase; they must include a final report and the delivery of all code/algorithms under both the IP condition Defcon 705 and under the Apache 2.0 licence, which thereby permits publication and making available open source.
• you should also plan for attendance at a kick-off meeting at the start of Phase 1, a mid-project event and an end of project event at the end of Phase 1, as well as regular reviews with the appointed Technical Partner and Project Manager. Meetings are expected to take place virtually, or local to Porton Down if in person.
• your proposal must demonstrate how you will complete all activities/services and provide all deliverables within the competition timescales (maximum duration of 12 months, with projects finishing no later than February 2025). Proposals with any deliverables (including final report) outside the competition timeline will be rejected as non-compliant
• your proposal must plan to deliver all the components to run the given algorithm with all new code covered by unit and integration tests.

15. What your resourcing plan should include

Your resourcing plan must identify, where possible, the nationalities of proposed employees that you intend to work on this phase.

15.1 If your proposal is recommended for funding

In the event of a proposal being recommended for funding, the DASA reserves the right to undertake due diligence checks including the clearance of proposed employees. Please note that this process will take as long as necessary and could take up to 6 weeks in some cases for non-UK nationals.

You must identify any ethical / legal / regulatory factors within your proposal and how the associated risks will be managed, including break points in the project if approvals are not received.
MODREC(https://www.gov.uk/guidance/defence-and-security-accelerator-ethical-legal-and-regulatory-guidance#mod-research-ethics-committee) approvals can take up to 5 months therefore you should plan your work programme accordingly. If you are unsure if your proposal will need to apply for MODREC approval, then please refer to the MODREC Guidance for Suppliers or contact your Innovation Partner for further guidance.

Requirements for access to Government Furnished Assets (GFA), for example, information, equipment, materials and facilities, may be included in your proposal. DASA cannot guarantee that GFA will be available. If you apply for GFA, you should include an alternative plan in case it is not available.

15.2 Failure to provide any of the above listed will automatically render your proposal non-compliant.

16. Export control for overseas partners

All relevant export control regulations will apply if a company ultimately wants to sell a developed solution to a foreign entity. All innovators must ensure that they can obtain, if required, the necessary export licences for their proposals and developments, such that they can be supplied to the UK and other countries. If you cannot confirm that you can gain the requisite licences, your proposal will be sifted out of the competition.

Additionally, if we believe that you will not be able to obtain export clearance, additional checks may be conducted, which may also result in your proposal being sifted out of the competition.

17. Cyber risk assessment

17.1 Supplier Assurance Questionnaire (SAQ)

On receipt of a ‘Fund’ decision, successful suppliers must prove cyber resilience data before the contract is awarded. The start of this process is the submission of a Supplier Assurance Questionnaire (SAQ). The SAQ allows suppliers to demonstrate compliance with the specified risk level and the corresponding profile in Def Stan 05-138, and the level of control required will depend on this risk level.

To expedite the contracting time of successful suppliers we ask all suppliers to complete the SAQ before they submit their proposal. The SAQ can be completed here using the DASA Risk Assessment RAR-145376382 and answer questions for risk level “Low”.
Defence Cyber Protection PartnershipThe Defence Cyber Protection Partnership (DCPP) will review your SAQ submission and respond with a reference number within 2 working days. The resulting email response from DCPP should be attached (JPG or PNG format) and included within the DASA submission service portal when the proposal is submitted. You will also be asked to enter your SAQ reference number. Please allow enough time to receive the SAQ reference number prior to competition close at midday (BST) on Wednesday 13 September 2023 (BST).

If the proposal is being funded, the SAQ will be evaluated against the CRA for the competition, and it will be put it into one of the following categories:

1. compliant – no further action
2. not compliant – if successful in competition and being funded, the innovator will be required to complete a Cyber Implementation Plan (CIP) before the contract is placed, which will need to be reviewed and agreed with the relevant project manager

Innovators can enter a proposal without all controls in place, but are expected to have all the cyber protection measures necessary to fulfil the requirements of the contract in place at the time of contract award, or have an agreed Cyber Implementation Plan (CIP).

The CIP provides evidence as to how and when potential innovators will achieve compliance. Provided the measures proposed in the Cyber Implementation Plan do not pose an unacceptable risk to the MOD, a submission with a Cyber Implementation Plan will be considered alongside those who can achieve the controls.

A final check will be made to ensure cyber resilience before the contract is placed. Commercial staff cannot progress without it. This process does not replace any contract specific security requirements.

Further guidance for completing this process can be requested by emailing the DASA Help Centre: accelerator@dstl.gov.uk.

Additional information about cyber security can be found at: DCPP: Cyber Security Model industry buyer and supplier guide.

18. Public facing information

When submitting your proposal, you will be required to include a title and a short abstract. The title and abstract you provide will be used by DASA, and other government departments, to describe your project and its intended outcomes and benefits. They may be included at DASA events in relation to this competition and in documentation such as brochures. The proposal title will be published in the DASA transparency data on GOV.UK, along with your company name, the amount of funding, and the start and end dates of your contract. As this information can be shared, it should not contain information that may compromise Intellectual property.

19. How your proposal will be assessed

At Stage 1, all proposals will be checked for compliance with the competition document and may be rejected before full assessment if they do not comply. Only those proposals that demonstrate compliance against the competition scope and DASA mandatory criteria will be taken forward to full assessment.

19.1 Mandatory Criteria

The proposal outlines how it meets the scope of the competition

Within scope (Pass) / Out of scope (Fail)

The proposal fully explains in all three sections of the DASA submission service how it meets the DASA criteria

Pass / Fail

The proposal clearly details a financial plan, a project plan and a resourcing plan to complete the work proposed in Phase 1

Pass / Fail

The proposal identifies the need (or not) for MODREC approval

Pass / Fail

The proposal identifies any GFA required for Phase 1

Pass / Fail

The proposal demonstrates how all research and development activities / services (including delivery of the final report) will be completed within 12 months from award of contract (or less), completing no later than February 2025

Pass / Fail

The bidder has obtained the authority to provide unqualified acceptance of the terms and conditions of the Contract.

Pass / Fail

The bidder must deliver solutions which can integrate with open, flexible , modular architectures. Algorithms must be written in object oriented Python, as components which are compatible and could be merged into the Stone Soup framework. Notes must be made on any breaking changes. The bidder should deliver all the components to run the given algorithm with all new code covered by unit and integration tests. Documentation should also be provided for any new components created. Guidance on code style, testing and documentation can be found on the documentation pages.

Pass/Fail

The Supplier is to deliver code/algorithm under 705 and Apache licence . Please note, Dstl not only requires to be able to share algorithms/code generated under this competition with the broader defence community, but also requires to secure the rights to publish/ open-source any algorithm and code generated. Consequently, 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. Please see the terms for this competition, here for further details.

Pass/Fail

The bidder must present evidence that they are willing to work with Dstl to arrive at a common understanding and direct how best to deploy novel algorithms in Stone Soup.

Pass/Fail

Proposals that pass Stage 1 will then be assessed against the standard DASA assessment criteria (Desirability, Feasibility and Viability) by subject matter experts from the MOD (including Dstl), other government departments and the front-line military commands. You will not have the opportunity to view or comment on assessors’ recommendations.

DASA reserves the right to disclose on a confidential basis any information it receives from innovators during the procurement process (including information identified by the innovator as Commercially Sensitive Information in accordance with the provisions of this competition) to any third party engaged by DASA for the specific purpose of evaluating or assisting DASA in the evaluation of the innovator’s proposal. In providing such information the innovator consents to such disclosure. Appropriate confidentiality agreements will be put in place.

Further guidance on how your proposal is assessed is available on the DASA website.

After assessment, proposals will be discussed internally at a Decision Conference where, based on the assessments, budget and wider strategic considerations, a decision will be made on the proposals that are recommended for funding.

Innovators are not permitted to attend the Decision Conference.

Proposals that are unsuccessful will receive brief feedback after the Decision Conference.

20. Things you should know about DASA contracts: DASA terms and conditions

Please read the DASA terms and conditions which contain important information for innovators. For this competition we will be using the Innovation Standard Contract (ISC), links to the contract: TERMS. We will require unqualified acceptance of the terms and conditions; if applicable, please ensure your commercial department has provided their acceptance.

More information on DEFCON 705 can be found by registering on the Knowledge in Defence site.

Funded projects will be allocated a Project Manager (to run the project) and a Technical Partner (as a technical point of contact). In addition, the DASA team will work with you to support delivery and exploitation including, when appropriate, introductions to end-users and business support to help develop their business.

We will use deliverables from DASA contracts in accordance with our rights detailed in the contract terms and conditions.

For this competition, £800K is currently available to fund proposals. There may be occasions when additional funding may become available to allow us to revisit proposals deemed suitable for funding. Therefore, DASA reserves the right to keep such proposals in reserve. In the event that additional funding becomes available, DASA may ask whether you would still be prepared to undertake the work outlined in your proposal under the same terms.

20.1 Phase 1 key dates

Dial-in

20 July 2023

Pre bookable 1-1 telecom sessions

27 July 2023

Competition closes

Wednesday 13 September 2023 (BST).

Feedback release

Thursday 9 November

Contracting

Aim to start November 2023 and end 12 months later completing no later than February 2025

21. Help: Contact the DASA Help Centre

Competition queries including on process, application, commercial, technical and intellectual property aspects should be sent to the DASA Help Centre at accelerator@dstl.gov.uk, quoting the competition title. If you wish receive future updates on this competition, please email the DASA Help Centre.

While all reasonable efforts will be made to answer queries, DASA reserves the right to impose management controls if volumes of queries restrict fair access of information to all potential innovators.