The curse of lengthy procurement cycles and regulatory hoops to jump through means military systems can be as much as 15 years behind their equivalents in the commercial world. At the same time there is increased pressure to provide more intelligent analysis of data assembled from diverse systems so soldiers are presented with a succinct summary of the battlefield situation to which they can quickly react. All this has to be achieved using equipment provided by multiple vendors, over low bandwidth comms and using relatively slow computers, while remaining compatible with legacy systems.
Through its work with the British Ministry of Defence’s (MOD) Defence Science and Technology Laboratory’s (Dstl) Centre for Defence Enterprise (CDE), Egham-based SME 2iC has developed a set of open standards called Lean Services Architecture. The MOD included it in its Generic Base Architecture (Gba) Defence Standard and proposed it for the Generic Soldier Architecture (GSA) to which future military systems could be asked to comply.
SME 2ic chief executive officer Graham Booth tells us more.
Berenice Baker: How did 2iC recognise the need for interoperability standards for military systems?
Graham Booth: We are a software company focussed on building software to integrate and coordinate systems. We started out in defence – chief technical officer and cofounder Nick Peach worked on army systems at IBM, and I’ve worked in defence previously as well, so we wanted to bring our experience to military wireless software.
Compared with the commercial sectors we’ve worked in, the software tooling that’s available in defence is terrible. We set up the company to make the technology used in the wider enterprise space available in environments such as the battlefield, emergency services and the emerging Internet of Things where you have limited technology but dynamic actors – who you’re talking to comes and goes and changes – which is very different to what you expect in a data centre.
BB: How did you start working with the Dstl?
GB: We’d been doing very similar work with the MOD so we submitted an open call to CDE to say we think there’s a clever way of doing this. We proposed a way of providing a service-orientated approach and open architectures into a tactical space, which addressed part of the Dstl’s Land Open Systems Architectures (LOSA) programme.
The approach we took was one that would be familiar in an enterprise environment, in that you enable people to take existing and future systems and build them in a more modular approach using open architecture. They can then plug into other things built to the same specification, so you don’t have to have everything made by the same supplier through one big contract.
So you take that concept but make it work within the constraints of a defence environment, which involves multiple vendors, low bandwidth comms, low-powered computers and a lot of legacy equipment. We provided a proof of concept to show we could make that approach work in that environment by providing a business service layer to existing systems.
BB: What happened next?
GB: We came up with our own internal interface standard for how we would talk to systems. The MOD liked what we did and said can we have a copy of that specification as part of the LOSA programme. We thought that was great – as a small company our own proprietary is not much use to anybody — and the MOD adopted it on a bunch of projects.
Called Lean Services Architecture, it specifies how you would define the interface and the required components you would need to have that modular architecture.
BB: What sort of systems does the MOD want to apply this to?
GB: We’re looking at the tactical environment down to vehicle, soldier and deployed base type systems in the battlespace, including armoured vehicles, infantry and forward operating base equipment.
The LOSA programme addresses brigade and down, as opposed to other systems where you’re looking brigade and up. We think it makes a real difference at that low-level platform level where you’ve got lots of things that you want to join up and interoperate, and move data seamlessly between them to achieve a better outcome.
BB: How could help reduce kit burden and increase battlefield effectiveness?
GB: A great example is at the moment every vehicle has one of every piece of equipment. If you take something like the Boomerang shot detector, you have to put one on each vehicle, and they’re heavy. However, if you put one on every third vehicle and share the information, you need two thirds less of the same equipment, but you have the same capability as you can share the information between them.
Soldiers can’t carry Boomerang – a unit weights 20kg – but if you had an infantry soldier working near a vehicle with Boomerang, you could send sniper-detecting information from the vehicle through the radio telling the soldier there’s a shot and at this specific position relative to him. You can give him that battle-ready information without him having to carry very heavy kit.
We did another trial at Shrivenham in March. We put a £3 Amazon webcam that weighed a couple of grams on a simulated soldier so we could send pictures from it to other soldiers or the company commander, so he can see what the guy’s looking at but without adding any burden to the soldier.
BB: What else could Lean Services Architecture help with?
GB: At the end of last year we did another project which addressed the issue of integrating systems in different security domains. Or if one of those systems was a French system and one was British, how would you interoperate them using this open standards approach?
We put together a project called Cross-Domain Barrier that did this and won the DSEI innovation award in September last year for it. It shows how you can take an open system and build on top of it to address that coalition interoperability problem that no-one can solve.
BB: What other challenges in the military environment does it address?
GB: What a lot of people forget is that the MOD has got a lot of legacy stuff, and they’re not going to get rid of it. We’ve worked on showing how it can integrate with existing equipment; it just plugs in and you don’t have to rewrite it.
We’ve also radically decreased timescales. In some of the trials we’ve done, we’ve adapted existing systems and integrated them into these architectures within a matter of days, and changed how they react to each other in minutes rather than months and years. It’s an order of magnitude of difference in speed.
As we move into contingent operations, we’ve no idea what we’re going to be doing in six months’ time. If our procurement cycles are 18 months to get a requirement, 18 months to procure and another two years to get into service, five or six years is a quick procurement cycle. Our theatre of combat changes about every six months, so that is massively out of kilter.
We showed as part of this Lean Services Architecture that by using open standards you can address this while maintaining flexibility and adaptability. We provide a way of doing that with the existing stuff we’ve got.