The Defence Digital Network
A forum for airing and sharing concepts and ideas between the defence sector and other market sectors... View more
Defence & Digital
-
Defence & Digital
Defence & Digital
Work is being undertaken to implement a Defence Digital Transformation. Recently, several prominent figures have been appointed to further that objective. In this sense, ‘defence’ includes homeland security with its response to civilian threats and disasters, not only terrorist or cyber related but also natural ones such as flooding and those need to mitigate Covid and similar major impacting events. In such circumstances police, ambulance, fire-fighters and others (e.g. NHS, water, electricity and gas provision) may need to be supplemented by the armed forces. This poses the question about what changes are needed individually for each of these responders, in addition to their coordination.
The common thread, important to this community, is clearly digital twins. The picture is still emerging but below (The likely route for new-product development) is my summary of the likely direction to be taken by the key players. It summarises and builds on work undertaken by TDI, the DT Hub’s guidelines (DT Tool-Kit and other work), plus multi-domain integration considerations sponsored by the Government.
Following the summary, and expected discussion around it, I intend to invite open discussion about aspects that it raises, for example:
1.     What lessons come from previous model-based requirements’ capture and use of scenarios?
2.     Does this formalisation of process detract from the freedom of design teams?
3.     Customer and all stakeholder engagement is central to this process. Test Engineers often encapsulate a good balance between technical aspects and customer management. So, is offering more responsibility to Test Engineers a route to mitigate the claimed shortage of suitably qualified and experienced people (SQEPS)?
Sectors outside defence have already trodden this path and so I hope that people with that experience will also contribute. The ideas and experiences will contribute to the thinking and planning in the defence sector.
Â
The likely route for new-product development:
Requirements:- The use of high-level software models to define requirements is being advocated. The models will represent only the item (equipment) to be produced and will be independent of environment and other models. Scenarios aimed at demonstrating what is required of the new equipment will be prepared. A federation of models and the forthcoming Defence Synthetic Environment will be created to run the scenarios. Later in the project the models will become physics/mathematical accurate representations, at this stage they would be more akin to training models being ‘visual-only’, as used in computer gaming. These are simpler to generate and change. A main purpose is to allow users, and all other stakeholders, to participate in requirements’ validation and achieve buy-in to the project.
Lifecycle:- The intent is to add detail to the initially validated requirements’ model as the project’s design and development lifecycle rolls out. A key feature is that the original scenarios should produce the same test and evaluation results at each iteration to verify that the implementation of the current stage has remained on-track – or not. This will make it easier for DE&S Project Managers to monitor project progress and to know when to call dstl (Design Authority) back to arbitrate. It is understood that ‘the model’ may actually be several models – sometimes called an eco-system of models. A typical eco-system would include supply chain information, stock availability, documentation database etc. that would be linked and interdependent using a common parameter database. Many of these could be shared between several projects so that re-using ‘templates’ from previous work becomes viable and highly cost-effective.
Digital Twins:- The final testing stage would be part of acceptance before any real-world trials are undertaken – thereby further reducing risks and costs, as well as being more environmentally friendly. Taking it a stage further, a copy of the ‘as built’ model(s) would be delivered with each equipment and, at that stage, it becomes a ‘digital twin’ of the delivered entity.
The digital twin can then be used in parallel with the real entity to assist with identifying any need for preventative maintenance. It can also be used to ‘look-ahead’ to predict if/how the equipment could be used best in a forthcoming engagement. This may be a new scenario and federated with other models to form a task force. In a multi-domain operation, such as required to respond to a civil disaster, the twins from all participating domains would feature in the scenarios, ideally in the same synthetic environment.
Feedback & Feed-forward:- The introduction of digital twins offers a significant change to existing in-Service support as well as strategic and tactical planning. it also offers a mechanism to link learning from the in-Service usage back down the supply chain to the design stages for subsequent updates or related projects. Involvement of users at a very early stage is built-in, so their buy-in and ideas can be incorporated at cost-effective points in the lifecycle. It also promotes re-use, particularly of model components, even after the original equipment is retired.
Summarising:- Adding up the amount of changes needed and the benefits, the digital approach leading to digital twins is thought to be a ‘good thing’. Initially, most benefit may be achieved in the specification, design and development stages, with post-delivery benefits being realised once a significant family of twins have emerged.
So, what next?
Your engagement is needed to provide the most effective transition along the Defence Digital learning curve. Please comment, add your views about the 3 aspects listed above, add more topics – there are no wrong answers and few boundaries on what will be considered.
Many thanks for your time to read this and I look forward to hearing your views and experiences.
Dave
Log in to reply.