GVA / Vetronics design considerations

The Generic Vehicle Architecture (GVA) approach - as I know it - was originally taken by the Ministry of Defense (MOD) in UK to design electronic and power architectures, and Human Machine interface (HMI or crew interface) for rugged integrated vehicle electronics applications (aka Vetronics).

Important drivers behind the approach was - through standardization - to ease and simplify platforms installations ensuring Command, Control, and Communication systems (C3/C4), Mission systems, and Combat systems working together (including sharing of processing and storage), avoid integration conflicts, and perform midlife upgrades and technology insert more rapidly to address new threats and scenarios (e.g. by adding new sensors). Last but not least; to reduce the total cost of ownership (TCO) through the life span of the platforms (incl. by avoiding vendor lock ins). 

"The purpose [...] is to [...] realize the benefits of a standardized Open Architecture (OA) approach to land vehicle platform electronic architecture design and integration"

People often consider GVA as a design guide for electronically, electrically and physically design "only", but the standard even describes SW and communication architecture (Land Data Model*); defining open standard data interfaces (OMG DDS**) and behavior between components of the modular architecture to ensure interoperability between different vendors sub-modules used in a distributed system. In addition, normally GVA RFP's call for compliance to DEF-STAN 00-82, describing how to configure video/audio streaming using the in-vehicle Ethernet LAN network. 

"The specific GVA requirements within this standard reduce the design freedom and constrain implementations with the goal of achieving vendor independent system interoperability".

Data Respons have worked with numerous rugged vehicle electronic project during two decades, hence we have accumulated vast know-how and experience in how to design both HW (electronics, power supplies and mechanics) and SW for such Vetronics applications. An important take-away have been that (even if the goal of the GVA standard is to reduce design freedom to achieve vendor independent system interoperability), there are room for interpretation. Still, all roads lead to Rome - or do they? 

As mentioned above, the first GVA standard (DEF-STAN 23-09) was developed by UK MOD, but today, also other countries' armed forces have adopted the standard (e.g. Australia with their ASGVA). Even NATO have adopted the standard (NGVA or STANAG 4754). But if you read their specifications carefully, you will find that they sometimes differ from the "original". It might not differ a lot and it may not conflict to much with the original idea of GVA, but it still makes life for Tier 1 sub-suppliers like Data Respons somewhat challenging (having to read the specification as the Devil's Advocate, helping OEM's and end users avoid unpleasant surprises). Different GVA specifications may call for alternative connectors (typ. MIL-DTL-38999 or the German VG-type), different connector pin out (typ. of Ethernet, USB and Power), additions to the front panel bezel layout, and so on. So going to the market with a off the shelf GVA display or GVA computer which cover all countries' vetronics programs, is not really possible without offering different configuration options or customizations.

• Figure above from DEF-STAN 23-09 part 2 (HMI)

Another factor which may cause some headache for commercial and military off the shelf (COTS/MOTS) vendors, is the broad variation in panel sizes, functionality, and performance of the multi-functional GVA displays.

While some programs require 10,4" panels, others require 12,1" or 13,3" (we have seen vehicle programs calling for everything from 6" to 21,5" panels). And when you think you've got all the MIL-DTL-38999 (or VG) I/O interfaces right (typ. dual Gigabit Ethernet, DVI, and USB, with optional Composite video, CANbus and Serial-COMs), some programs may require some really legacy or custom I/O.

When some RFQ's call for low performance, reduced instruction set computer (RISC) designs, others may call for high performance Panel-PC's with x86 Xeon/Core-processors and massive local data storage. And if your off the shelf design have cable entry at the bottom (but which your clever design support 180 degrees rotation to offer optional top entry;-), you may find that the RFQ calls for side or even rear cable entry...

"Be selective when to use SHALL"

A friendly but important feedback to the system integrators and end users from our side, is to be very selective when to use SHALL, MIN and MAX requirements in their RFQ's (unless you have already established a clear understanding of availability through your initial RFI or RFP process). 

A modular design can of course solve some of the challenges, but unfortunately, modularity in design quite often increase complexity, increase cost... And if you shall win the large vehicle program contracts, cost is as important as functionality, quality and on-time delivery. A though one, this one. 

Similar challenges can be found when bidding for GVA computers where there is no real form factor defined (except it shall be Size, Weight and Power (SWaP) optimized"; often described to as "as small as absolute possible")). Quite a few vehicle programs calls for 1/2 19" (aka half 19", 19-2 or 220 mm) equipment for half rack mounting or for mixing of 1/2 and full 19" equipment in full rack cabinets, but too often, the system integrator has only been given a small envelope to squeeze in the computer between existing wall- or floor-mounted equipment. 

• Figure above: 1/2 19" computer developed by Data Respons Solutions

The Data Respons Solutions' approach to new GVA projects is to ensure we have all the HW and SW design competence - as well as MIL-test and -qualification know-how - available in-house, that we maintain a good partner base of component and board suppliers, panel manufacturers, as well as Electronic Manufacturing partners (EMS), and that we maintain a relevant portfolio of already approved sub-modules, 28VDC power supplies and LCD-panels in various sizes. All this to ensure rapid proof of concept and prototyping, and shortest time from contract award (by Prime or system integrator) to actual deployment.

In addition, we have in-house SW and firmware competence including DDS competence so that we can assist our customers - the systems integrators - beyond "just" delivering the piece of hardware. 

• Figure above: Operating and storage design criterias of vetronics systems

• Figure above: IP-testing of vetronics system developed by Data Respons

*) The Land Data Model (LDM) which defines data interfaces and behavior between components of the modular architecture, is an integral part of the Land Open System Architecture (LOSA) which - in addition to GVA - also cover the Generic Base Architecture (GBA) and Generic Soldier Architecture (GSA)

**) OMG / DDS: Object Management Group / Data Distribution Services