Generic Vehicle Architecture

374

In the last few years there has been a quiet revolution in the Ministry of Defence, the first of two key elements that have delivered Foxhound is a more realistic approach to trading off requirements against time and cost.

I think Foxhound is a genuinely innovative vehicle that has the potential for great export success. If it lives up to the expectations then its manufacturers have a bright future but we should also recognise the sensible approach the MoD took to requirements and the overall acquisition strategy. Of course there were baseline requirements such as protection, weight and mobility and the final competition for the LPPV resulted in only 2 vehicles making the cut but this was different to many previous projects where inflexibility on specification has led to cost and time into service increases.

The second key element is called Generic Vehicle Architecture, a revolutionary standard that no one has ever heard of.

GVA, or Def Stan 23-09 is an open standard designed to place information at the heart of a vehicular system. The objective of GVA is to create a single, standard digital electronic and electrical architecture for UK vehicles

DefStan 23-09 defines physical and communications interfaces on a vehicle to allow interchange of equipment and provides definitions of the Human Machine Interface.

The official objective is;

The purpose of this Def Stan 23-09 is to enable the MOD to realise the benefits of an open architecture approach to Land platform design and integration, especially in regard to platform infrastructure and the associated Human Machine Interface (HMI) in order to improve operational effectiveness across all Defence Lines of Development (DLOD), reduce integration risks and reduce the cost of ownership across the fleet. This is achieved by mandating and applying the appropriate interface standards

Taking a list from the standard itself;

The nine basic principles of the GVA approach and Def Stan 23-09 are that they must:

  1. Take account of previous MOD investment;
  2. Be applicable to current and future systems;
  3. Use open, modular and scaleable architectures and systems;
  4. Facilitate technology insertion (upgrade, update, replace, repair, remove and addition);
  5. Not needlessly implement in hardware any functionality that can be implemented in software;
  6. Take a ‘whole platform’ systems view, though life (including cost);
  7. Be done in conjunction with industry and all relevant MOD stakeholders;
  8. Be MOD owned and maintained
  9. Specify the minimum necessary to achieve MOD’s desired benefits avoiding unnecessary constraint in implementation.

Advantages of GVA include;

  • Vehicle availability and reliability will be improved , instead of wasteful time based maintenance intervals, conditions based maintenance will be possible
  • Availability based contracts will be possible as vehicle usage data will be available on which to negotiate against
  • Vehicle running costs can be reduced because condition based information will again be available
  • Processing and storage can be shared across multiple systems
  • Vehicle capability can be increased as sensors could be shared and intelligence automatically gathered and presented
  • Costs will be reduced by avoiding supplier lock in, increasing competition and lowering the barriers to entry for smaller manufacturers
  • Weight and power requirements will be reduced as equipment specific cabling will be eliminated
  • Reduced training
  • Reduced space for ‘systems equipment’
  • Vehicles can be quickly re-configured for different roles
  • New sensors can be quickly fitted to vehicles to counter developing threats, this can be done quickly, in essence, plug and play for sensors

In 2008 the Force Protection and Mission Systems Working Group was formed by the MoD and industry with the objective of addressing the increasingly difficult challenges of vehicle power management, man/machine interfaces and the vehicles system architecture.

Building on other projects including Vehicle Systems Integration (VSI) and Vehicle Technology Integration Demonstrator (VTID) GVA is big on open standards. The VSI group has been led by QinetiQ since 1997 so some of these programmes have a depth of knowledge that supported the rapid evolution of GVA, especially the vetronics aspects.

The MoD, QinetiQ and IBM, in conjunction with a range of collaborative partners including Selex , IVECO, Supacat; Raytheon, RTI, L3 Communications, Paradigm, MaxOrd Ballistics, Aeroflex, Hypertac, Polar Com,  Smiths Detection, Allen Vanguard, Britannia 2000 , GE Aviation and many others published the standard in August 2010, with an agreed 18 month revision cycle.

Generic Vehicle Architecture compliant display
Generic Vehicle Architecture compliant display

Available here for all to read it is also important to understand the difference between GVA and the standard, GVA is the approach and the standard is one output from this.

Although the physical and electrical connectors form a fundamental part of the standard it is the use of a middleware model that enables equipment A to exchange data with equipment B, both from different manufacturers. The Data Distribution Service (DDS) middleware system was chosen and the Land Data Model subsequently released.

The Land Data Model has been published (apart from certain restricted elements) and is freely available for suppliers, it is what is defined as a System Data Dictionary, published in standard Object Management Group (OMG) UML notation.

Thales are the design authority for GVA on the first fully compliant vehicle, the Foxhound, this is of course a relatively simple vehicle but it is a confidence building evolution and therefore eminently sensible.

GVA also addresses legacy issues with a well thought through transition model, GVA compliant equipment can be used with legacy equipment through the use of gateways, firewalls and adapters. Mastiff and Panther have GVA compliant equipment integrated into a non GVA compliant system.

The current version addresses mechanical standards, power infrastructure, video, human machine interface, health usage and monitoring (HUMS) and the electronic infrastructure but future versions might also cover communications, high voltage power and electric drives.

The three network types of safety critical (TTP), deterministic (MilCAN) and high speed (Ethernet)

Other manufacturers are beginning to offer ‘GVA Compliant’ products, a clear sign of the standards maturity.

GVA is also being joined by the Generic Base Architecture and Generic Soldier Architecture, more open standards.

Although this may seem a rather dry subject, its importance should not be underestimated.

Not all of the stated benefits may ultimately be realised but the MoD should be roundly congratulated for sticking to its guns on GVA and seeing it through, it creates a baseline for innovation and competition, avoids supplier lock in and provides an enabling core for future expansion.

Shame no one outside the defence industry has ever heard of it.

newest oldest most voted
Notify of
Michael (Civ.)
Michael (Civ.)

I read this and the comparision/analogy i thought of was the IBM-Compatable PC.*

My very first PC was a second or third hand DX4-100.

Nearly two years ago i bought an overclocked AMD Phenom II. From one to the other in the space of 11 years. Could this sort of standard have the same effect for the architecture of Military vehicles?

If it could, where are we going to find the money that will be needed to keep up with the pace of change?

*not sure if it’s a relevent analogy, it’s just the first thing that came to mind

Gareth Jones
Gareth Jones

Very interesting TD.

Could something similar be used for ships/aircraft or are they simply too complicated?

ArmChairCivvy
ArmChairCivvy

Hi GJ,

Data connectivity of course involves protocols and other “stuff” at the logical level. Interestingly I looked at IPO’ing a solution where power and data share cabling, data including not just transfer/ broadcasting but automatic, continuous monitoring and diagnostics. So this would be a physical-layer enabler for a[ny] data architecture, or quoting from the leading-in article “Although the physical and electrical connectors form a fundamental part of the standard it is the use of a middleware model that enables equipment A to exchange data with equipment B, both from different manufacturers.”

An aircraft/ helo manufacturer or a shipyard could dramatically reduce their production and fitting out costs, but they have umpteen clients who all have their own (legacy) standards to support. So only an informed customer, buying in bulk, can enforce these types of standards. Hats off for the MoD!They are spending (here saving) our money, after all.

Here’s my penny’s worth of the potential for just one subsystem of what is being addressed; as you can see from the figures, this quick-look assessment was undertaken a while ago:

The aircraft market can be divided to commercial and military aircraft markets. Both of these markets consist of a large number of distinct submarkets, which are differentiated according to size, range and the type of the aircraft. The total aircraft market size will average USD 90-110B annually between 2000-2019 (calculated from Boeing and EADS estimates). The estimate is that wiring sub-market will make up approximately USD 1B of this. Weight saving benefits and saved labour from reduced cabling and standardised connections have been calculated for Airbus models [NB This was before the CAD/CAM fiasco that caused all cabling to be done by hand on the new flagship model; the costs of that and the commercial liability have been widely published.]

The global helicopter markets are largely dependent on military demand because military helicopter sales generate over 80 % of the global helicopter markets. These are estimated to be approximately USD 8B annually (CSFB estimate). The helicopter markets have historically proved to be highly cyclical due to variations in military helicopter delivery schedules. The wiring markets for helicopters are estimated to be approximately USD 80M annually.The integrated solution is particularly attractive for these markets since it offers significant weight reduction *as well as higher EMC*.

The ship building sector consists of a large number of highly distinctive markets: cargo vessels, cruise ships & ferries and naval vessels. The overall ship market is estimated to be USD 100-150B (excluding naval vessels and calculated from Clarkson Research Studies/World Shipyard Monitor). Of this (the same exclusion applies) the wiring/electronics market is expected to make up approximately USD 1Bn (Standard & Poor’s 2000 estimate).

Dangerous Dave
Dangerous Dave

I’ve actually had a skegg at the DefStan, due to an earlier article on TD (CVRT 2.0). I realised that this would allow highly modular interior fits to standards compliant vehicles (i.e. re-rolling crew stations).
But also, the GVA also includes power and weapons station specs, not just data/comms/MMI. Thus it should be possible to retrofit and upgrade weapons mountings and power-packs much more easily.

Now, *that’s* an interesting thing to ponder . . .

Mark
Mark

From an engineering perspective I have to fully applaud what this document is about especially it wide availability failure to release this type of information early enough is a constant issue. The ability to cement interfaces for your major component at the earliest possible stage and stick to them is a extremely important first step. It allows supplier confidence and ensures the customer knows any change here will involve a serious cost penalty (this is not always well understood).

ACC “This was before the CAD/CAM fiasco that caused all cabling to be done by hand on the new flagship model” This was not the sequence that played out the cad bit was a problem but there was a number of steps and major decisions taken or not before the by hand bit.

Brian Black
Brian Black

GVA sounds like a great idea!

And it only took a financial meltdown and a major budget crisis for this type of common sense thinking to emerge.

Matthew Smith
Matthew Smith

GVA is being covered in quite some detail at this event, for those that are interested, along with a number of other Open Architecture in the US and Europe:

http://www.iqpc.com/Event.aspx?id=540166

Mr.fred
Mr.fred

Ahh, IQPC. Never, ever, let them get your details or they will hound you until the ends of the Earth.

Plus their events tend to be pretty weak as well.

Martin
Martin

Agreeing standards are vital of course to interoperability, but single/centralised approaches are not the only way to do this. There are significant costs to agreeing and maintaining agreed standards, not least of which is the time it takes to negotiate what happens when new components or interfaces need to be added. Are they added without agreement, or delayed until agreement? These costs need to be traded against the supposed advantages listed above, not lost.

To get around these problems, such standards can rapidly become too watered down or abstract to be of any practical use, and simply act as another layer of trivially-fulfilled requirements as, say, frequently happens with MODAF.

Or they are bypassed as we see with the situation awareness descriptions that require descriptive text, because the land data model is insufficient even in Helmand.

As an exercise in discussing and working through the integration problems: Good. As an output requiring prescriptive compliance: Bad.

↓