Return to User Experiences

Return to Top

DDS as an enabler for armoured fighting vehicle equipment and systems integration. In service and future defense vehicle systems comprise an increasing range of attached equipment and systems. These require frequent refresh and addition to mitigate emerging threats and maintain operational edge.

This seminar will introduce the use of DDS as a key element of the UK and NATO Generic Vehicle Architecture (GVA) standard. The GVA standard uses DDS to assure modularity and delamination of vehicle system elements and to underpin data standards for vehicle information. These in turn reduce the equipment needed and effort required to integrate existing and new platform elements.

The seminar will explain the use of DDS using production examples as a key part of the GVA to provide platform management systems, and further up the value chain to platform mission systems and extensions to secondary platforms such as unmanned ground vehicles.

Return to Top

Return to Top

Thank you for the introduction and hi to everyone where ever you are. In the next 20 minutes, this is going to be a challenge to get through all of this. I am going to explain some of the challenges around integration within modern defense vehicles. Why software is important in that role and I think you can all recognize that.

A bit about the General Vehicle Architecture standard, where did it come from? how does it use DDS? and Why does it use DDS? Something that is important to me, in all of this is what does the user get out of the implementation with DDS and some ideas of what we can use within the DDS world next in this problem space and a bit of context.

Moving on swiftly then.

Figure 1: Seminar Content

Return to Top

So what are the challenges associated with defense vehicles

Figure 2: Picture of a UK Panther; Defense vehicle integration challenges

Return to Top

Figure 3: Pitcure of a UK 'Warrior' vehicle; Software is essential to exploit open standards based vehicle architectures

Return to Top

GVA is the UK/Australian mandated standard for OPEN vehicle architectures. (NGVA is based on GVA). It covers:

Figure 4: (NATO) Generic Vehicle Architecture Components

Return to Top

Both the UK Ministry of Defense (MOD) and the North American Treaty Organization (NATO) require the use of DDS.

• Enables system of systems approach (modularity and connectivity)
• Platform agnostic
• Mature, multi-vendor standard
• Minimises data on the wire via Quality of Service (QoS)
• Robust – no single point of failure
• Efficient
• Scalable
• Standards defined data model driven code generation
• Distinct middleware layer that could be replaced in the future
• Used for quantitative data rather than streamed data (e.g. video and audio)

Figure 5: Why (N)GVA uses DDS

Return to Top

Benefits:

• GVA HMI: human factors, shared SA, reduction in training need / skills fade (other platforms)
• Application: roles, security, alarms, HUMS etc. Systems Integration, (FC Comms), offboarding
• GVA messaging (DDS): through life & capability insertion, data interchange
• Network – ease of access (SWAP)

The network gives the benefit of reduced Size Weight and Power (SWAP) you don't need to have lots of different networks, you just can plug into the same network. On top of DDS we have the standard messaging system which means if we plug in something like a laser range finder, the finder has a set of information it should publish some may be mandatory, some may be optional. So, if we plug in a laser range finder on the left hand side there is a sensor and the code on the right hand side and the HMI will recognize it. So on the right hand side you have a core piece of software, a set of services that takes DDS as a messaging system and turns it to a electronic architecture. The things you need to manage the data on the platform for instance roles. The commander has different roles and different set of capabilities than the driver, or help and usage monitoring, or timing you need to bring all the equipment on the platform to the same time base so we can fuse their data. Then the HMI, generally, is produced for each crewmember so everyone on the platform can view and use the same data subject to their roles.

Figure 6: GVA high level architecture and benefits

All vehicle systems connected to the data bus using GVA DDS are resources. They can represent something as simple as a cabin light to as complex as another subsystem with multiple components and processors

Return to Top

A service resource is a specific type of resource, rather than a piece of hardware it is a service defined by GVA such as GVA Registry Service, Usage and Condition Monitoring Service.

Return to Top

A service resource is a specific type of resource, rather than a piece of hardware it is a service defined by GVA such as GVA Registry Service, Usage and Condition Monitoring Service.

Return to Top

A Crew Intelligent Display (CID) resource is a specific type of resource that includes the interface for a single screen or crew member.

Return to Top

A gateway resource is a specific type of resource that translates between another data bus (often legacy) and the GVA DDS data bus. The J1939 CanBUS gateway is of particular interest because while other legacy data buses may be replaced over time with GVA DDS compliant resources the underlying vehicle platform is like to continue to use j1939 as it is a well established protocol.

Return to Top

The GVA DDS data bus uses standard DDS and GVA defined data types. Vehicle integrators are at liberty to add nonGVA DDS topics for any data required that is not defined by GVA

Figure 7: GVA based vehicle data architecture

Return to Top

• GVA Defines Data Types
• GVA Defines a Type Naming Convention
• GVA Defines a Topic Naming Convention
• GVA Defines DDS Domain ID Allocation Rules
• GVA Defines QoS Policies
• GVA Uses IDL Inheritance to reduce the number of topics on the wire
• GVA Uses X-Types to aid backwards compatibility between versions
• GVA tools create IDL from the model for DDS implementation

Figure 8: How GVA Makes Use of DDS (Highlights)

Return to Top

As of all standards, How is it developed? When talking about the Land Data model, its been collaboratively brought together in industry. This is a picture of the Land Data Model group in progress. Man pointing at the screen is an CGI employee, but around the room we got UK and European manufactures there talking about how it all works.

Figure 9: GVA data standards developed collaboratively with industry

Return to Top

The sensors module provides data for use by an environmental sensor of some sort. It provides a few specific known sensor types and a method of defining a generic sensor of a type not specifically represented in the PIM.

Figure 10: Example Platform Independent Model (PIM) Module: Sensors

Return to Top

I said I was going to talk about the Machine Interface, and I've got passion about how the users get benefit from it. So this is a typical UK GVA Human-machine interface (HMI). Looks a bit boring, got a status bar at the top and some bessel's around the edge. My explanation for this system is that its designed for the 0.01% use edge case. You are working in a vehicle moving at speed, on rough ground, you're under a nuclear biological chemical threat, you have the thickest gloves on you have ever seen, you can hardly see through your goggles, its night, you haven't slept in two days and someone is trying to kill you. You're under extreme stress and the fear of dying. This interface is designed to be so intuitive. People use it without thinking, very easy to use.

• ALL systems and platform accessed through one screen
• Physically and cognitively designed for use at speed using NBC kit
• FUNCTION over FORM
• 0.01% use edge case

Figure 11: GVA Human Machine Interface (HMI)

Return to Top

Here is a GVA system in use in the Warrior CSP, thanks to Lockheed Martin we have the ability to show the picture, that it shows how uncluttered the turret is. If you've ever been in a defense vehicle turret, they usually have so many screens and so many buttons you can hardly move in them. This one is completely uncluttered because you have the single screen in front of you. What does this give you? It gives shared situational awareness, everybody in the vehicle has a single screen in front of them and they can all see what's going on. Screen on the right is a picture of some recent work we have done controlling an unmanned ground vehicle, so the commander can see what's going on from the unmanned ground vehicle while someone else is driving, or its driving itself, so everyone can see what's going on. As you can see there is a map in the top right corner so that gives you shared cognition, the commander will have a different thing to do with the data as the guy driving the whatever. That gives an information edge, able to spot things quicker, make decisions faster, on the battlefield seconds count. Its a simple and consistent interface, you have standard systems, dashboards, and specific mission systems, like the Unmanned Ground Vehicle (UGV).

Figure 12: GVA – the user perspective

Return to Top

We always need to think in terms of the users, and they usually have shiny boots and wear shiny pajamas. So what are we going to do for them? That's quite difficult to explain when you're down in the technical details…

• GVA defines a method to distribute for QoS policies to the resources on the data bus: COTS DDS systems connect with no modification.
• Use DDS-Security to enable different classifications of data to exist on the same wire?
• Time sensitive networking integration?
• Use DDS on unmanned vehicles to manage resources, with gateways to robotic standards (ROS)?

Figure 13: What’s next?

Return to Top