Pathways Towards Multi-Domain Integration for UK Robotic and Autonomous Systems

This paper examines how multi-domain integration for robotic and autonomous systems (RAS) might be approached. Though it focuses specifically on RAS, a function of a focus on the Multi-Domain Integrated Swarm programme, its lessons can be transferred to integration more broadly.

The authors find that:

• The pursuit of integration can lead to counterproductive outcomes if its scope and optimal operational use cases are not properly defined.
   
• Bodies such as the Integration Design Authority (IDA) will need to consider the operational use cases which frame their work. Historically, problems have often been created when adoption of standards and programme growth have been driven by a need to demonstrate integration for its own sake, rather than being guided by operational use cases.
   
• Integration ought to be approached on a tiered basis. The degree to which capabilities will need to be integrated will vary by functional use case. Therefore, standards as defined by bodies like the IDA should be defined contextually, rather than aiming for universality across Defence.
   
• There are some considerable advantages to cross-service integration, but also costs in terms of the ability to specify and enforce standards in areas like data. Approaches which depend on backwards integration can mitigate these challenges, but at the cost of specific operational vulnerabilities to both kinetic attacks on key nodes and cyber attacks. Therefore, cross-domain integration in any given use case should be assessed in terms of the operational utility gained weighed against the challenges that implementation will create.
   
• The areas of the battlefield where there is greatest utility to cross-service integration are those like the littoral and close areas of the land operating environment where the capabilities of multiple services will converge at scale.
   
• In areas like deep zones or blue water, by contrast, the capabilities of specific services will still likely predominate, incentivising a single-service-led approach to integration comparable to that which led to the US Navy’s Naval Integrated Fire Control – Counter Air architecture.
   
• Coordination with operators to identify specific use cases through things like operational analysis will be critical. A top-down process led by technical parameters will encounter resistance, non-adoption and slow-rolling behaviours from the operational level.
   
• In the medium to long term, hardware may come to define integration. Increases in processing power at the tactical edge may enable new approaches to both network integration and translation across data formats, circumventing today’s challenges around waveforms and data standards. However, integration at the edge will require platforms to meet certain hardware standards. This is currently a frontline command-controlled matter under the Levene model (the existing Ministry of Defence approach to procurement, which empowers the services to make key choices), which creates a tension with centrally managed integration change-management programmes.
   
• In the medium to long term, the software-led approach to digital strategy will need to embrace hardware standardisation and coordinated procurement. This will require central bodies like Strategic Command to act as facilitators in a service-led process resembling the 31 US initiatives which led to AirLand Battle.