Home / News / From The Lab to the Field: A Case Study on Integrating Third Party Systems Using Digital Twinning

From The Lab to the Field: A Case Study on Integrating Third Party Systems Using Digital Twinning

Advancements in technology have allowed us to level up our testing capabilities significantly over the years. Digital twinning in particular has given us the opportunity to represent physical devices, environments, or users that we don’t have regular access to in a controllable and reproducible manner.

In this second case study on digital twinning, we sat down with Rab Wilson, TacCIS Solution Architect, and David Attwood, R&D Engineering Manager, of General Dynamics United Kingdom Limited to hear about their experiences in using digital twinning. In particular, we discussed how their engineering teams are integrating third party systems and collaborating with relevant stakeholders within systems like Bowman, the tactical communications system developed by GDUK and used by the British Armed Forces.

When asked what the benefits of using such technology really boil down to David explained: “It’s all related to the logistics and not having to consume expensive hardware and lab resources. We can set it up and people can access it from their own sites, essentially removing the need for us to get a lab full of stakeholders in to test each individual theory.”

When you’ve got multiple suppliers on a particular program, maintaining a schedule for in-person integration testing can be exceptionally challenging, not to mention, expensive.

Once a digital twin environment is setup, it is relatively simple for our engineering teams to change configurations and run a number of hypothetical situations, often more flexibly and efficiently than we could do within a lab or on-site.

“It’s never going to fully replace a lab, but what it does, is allow you to raise the learning curve and de-risk things as quickly and early as possible,” says David. “There’s that element of a sandpit environment where it gives our partners more flexibility to play themselves without disrupting other work that we may have going on.”

But digital twinning isn’t just about hypothetical cases and endless testing. It helps us to ensure that when we do have face time with customers and partners that our solutions are going to do exactly what we want them to allowing us to show up to these engagements with a high level of confidence.

Over the past year and a half, we have been working to support the British Army’s delivery partner ROKE with Project ZODIAC at the Land System Reference Centre in Blandford, England on a trial to integrate ZODIAC concept demonstrator components with the Bowman network.

Rab explains that the biggest issue we were trying to solve was how ZODIAC would use the Bowman network and whether the network would be able to support the level of traffic required. So, we asked ‘What traffic are you actually sending?’ And once we understood it would mostly be small information messages (e.g. target reports) and got a sense of the frequency at which it was being sent, we could start to draw conclusions on how the network could support Zodiac use cases.

”I think fundamentally,” he explains, “We go back to the first principles of engineering. What problems are you trying to solve? What is the question you’re trying to answer? And I think it (digital twinning) almost becomes a toolbox of options to help answer those questions”

Within that toolbox are elements like virtual representations, models, and sometimes analysis of information gathered from previous exercises. “It’s about understanding the question,” says Rab, “then using that to determine the optimal level of fidelity in the solution or the method, in order to answer that question.”

He further explains that we had two techniques to deploy to answer that question. The first was to look at test data from previous large scale deployments, then reading across where the information exchanges were similar. The second was to use an existing simulation model that had been calibrated from work that had previously been done on a large scale physical test. This model also had some representations of the Bowman protocols in it, which gave us confidence that the results would be reliable.

Through this exercise, we were able to determine that – given the size and frequency of the data – it wasn’t going to be an issue and we turned the risk into an evidenced account of how the network could support what was needed.

“One of the key advantages of a digital twin is you can plug in real users at the edge and they can start to see what the responsiveness of the system is and get a feel for that in a battle context,” explains Rab. “A number on a sheet which says it will work is very different to sitting there and waiting for a file to go through.”

Both Dave and Rab signal that there is more to come in terms of our use of digital twinning and that, quite possibly, we are just scratching the surface of its potential.

“I think it’s the power it gives in the future,” says David, “in terms of being able to build larger deployments; being able to use this in that collaborative training environment where you can represent more of the adjacent forces rather than using it on a company level.”

Scroll to Top