DDS Foundation Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Use Case 5: General Vehicle Architecture (GVA) ======
[[ddsf:public:guidebook:03_user:start| Return to User Experiences]]

===== Details =====

^ Author        | Dr. Richard Saull |
^ Title         | Subject Matter Consultant | 
^ Organization  | CGI Secure Platform Systems, UK|
^ Date          | 28 October 2020 |
^ Time          | 32 minutes  |
^ Presentation  | [[https://www.brighttalk.com/webcast/12231/443332/dds-use-case-generic-vehicle-architecture-gva]] |
^ Document      | [[http://public2.brighttalk.com/resource/core/304763/dds-foundation-cgi-gva-case-study-v11_678237.pdf]]   |

===== Abstract =====
[[ddsf:public:guidebook:03_user:07_gva| Return to Top]]

[[ddsf:public:guidebook:06_append:glossary:d:data_distribution_service_dds|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. 

===== Presentation =====
[[ddsf:public:guidebook:03_user:07_gva| Return to Top]]

===== Seminar Content =====
[[ddsf:public:guidebook:03_user:07_gva| Return to Top]]

/* 3:31*/

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 [[ddsf:public:guidebook:06_append:glossary:d:data_distribution_service_dds|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>
{{  ddsf:public:guidebook:03_user:screen_shot_2020-12-10_at_9.41.34_am.png?700  |}}
<caption>Seminar Content</caption>
</figure>


===== Defence vehicle integration challenges =====
[[ddsf:public:guidebook:03_user:07_gva| Return to Top]]

/* 4:16 */

So what are the challenges associated with defense vehicles

^ Increasing peer and insurgent threat | <WRAP>
  * Equipment proliferation: SWAP
  * Tempo of capability change / obsolescence
</WRAP> |<WRAP>This is a UK Panther vehicle, it’s a command vehicle, and as you can see it has lots of equipment bolted onto the vehicle, due to battle field conditions, terrain conditions or its obsolete.</WRAP> |
^ Usability                              | <WRAP>
  * Cabin clutter / ergonomics
  * Cognitive burden
  * Training burden
</WRAP> |<WRAP>This leads to the Commander not being able to see out the vehicle, he's surrounded by screens which leads to a high cognitive burden, must remember on each screen which menu to use, all integrated by a swivel chair. This can also mean a high training burden cause if the commander hasn't used the system in a while he might forget where things need to go. </WRAP> |
^ Fightability                           | <WRAP>
  * Shared situational awareness
  * Common operating picture
  * Information edge and decision making
  * The speed of relevance
</WRAP> |<WRAP>Leads to a lack of shared situational awareness, no common operating picture, the decision making is limited to the commander and his ability to use the information he has. If Others involved, they can do it quick enough.</WRAP> |
^ Cost and Time                          | <WRAP>
  * Vendor / prime lock-in
  * Software security and certification
  * Condition based maintenance
  * Equipment interchange between vehicle types
</WRAP> |<WRAP>Cost issues like software security and certification in a monolithic system is more expensive than a modular one. Benefits from condition-based maintenance, done properly move equipment between vehicle types.</WRAP> |



<figure>
{{  ddsf:public:guidebook:03_user:screen_shot_2020-12-10_at_9.44.36_am.png?700  |}}
<caption>Picture of a UK Panther; Defense vehicle integration challenges</caption>
</figure>


===== Software is essential =====
[[ddsf:public:guidebook:03_user:07_gva| Return to Top]]
/*6:21*/
^Hardware|<WRAP>
  *Sensors, Sights, Weather, ECM.
  *Effectors, Weapons, defense.
  *Platform: engine, power.
  *Majority of the cost/Majority of focus.
</WRAP> |<WRAP>When the army buys a vehicle, they tend to look at if its tracked or wheeled, how much armor it has, and how big is the gun? These are the things that are important to them when it comes the the battlefield. Usually comes with a network that joins it all together.</WRAP>|
^Software|<WRAP>
  *Control and Monitor
  *Information: Data in context & fused
  *Decision/Mission Aids (e.g., BMS)
  *~1% Cost, Mission Critical; Not Strength of hardware OEM
</WRAP> |<WRAP>But they don't really think about the software. You probably drove your car today, or recently, and inside your car it probably has a Drive-By-Wire control monitoring system that allows the network in the car to determine, from the amount of force on the peddle, the amount of throttle to unleash from the engine. Information: How fast you are going and then how fast are you in relation to the speed limit, so its putting the data in context. For example, the system could take your speed and the conditions on the road and automatically suggests to break. Decision Aids that are very important in the defense world. Battle Management Systems, the grand map of the situation of where everybody is, where you're being asked to go, and what you're asked to do.</WRAP>|
^Outcome|<WRAP>
  *Platform Control
  *Shared Situational Awareness
  *Shared Cognition (Teamwork)
  *Mission Success/Information Edge
</WRAP> |<WRAP>So if done properly the outcome associated with the right use of software used on the right hardware is that you can control the platform accurately, shared situational awareness, and you can work together because we have a sustained knowledge base of the situation, which leads to mission success.</WRAP> |

<figure>
{{  ddsf:public:guidebook:03_user:screen_shot_2020-12-10_at_9.51.43_am.png?700  |}}
<caption>Pitcure of a UK 'Warrior' vehicle; Software is essential to exploit open standards based vehicle architectures</caption>
</figure>

===== (NATO) Generic Vehicle Architecture Components =====
[[ddsf:public:guidebook:03_user:07_gva| Return to Top]]

GVA is the UK/Australian mandated standard for OPEN vehicle
architectures. (NGVA is based on GVA).
/*8:39*/
It covers:
^How to connect equipment|<WRAP>Power/ Ethernet</WRAP>|<WRAP>Mandates how to connect, using ethernet or power method.</WRAP>|
^How to communicate|<WRAP>[[ddsf:public:guidebook:06_append:glossary:d:data_distribution_service_dds|DDS]] messaging</WRAP>|<WRAP>Mandates how to communicate DDS Messages, also DDS is mandated in the GVA</WRAP>|
^How to describe items|<WRAP>Land Data Model (LDM)</WRAP>|<WRAP>Very strict rules on how to describe data moving around DDS(The Land Data Mdoel)</WRAP>|
^System look and feel|<WRAP>[[ddsf:public:guidebook:06_append:glossary:h:hmi|HMI]] – Not in NGVA</WRAP>|<WRAP>Guidelines for the look and feel for the users, not mandated because you don't know what's coming in the future</WRAP>|
^Storage of diagnostic data & Alarms|<WRAP>HUMS</WRAP>|<WRAP>Storage of diagnostic data and alarms to help the user.</WRAP>|
<figure>
{{  ddsf:public:guidebook:03_user:screen_shot_2020-12-12_at_11.40.23_am.png?700  |}}
<caption>(NATO) Generic Vehicle Architecture Components</caption>
</figure>

===== Why (N)GVA uses DDS =====
[[ddsf:public:guidebook:03_user:07_gva| Return to Top]]
/*9:55*/

Both the UK [[ddsf:public:guidebook:06_append:glossary:m:mod|Ministry of Defense (MOD)]] and the [[ddsf:public:guidebook:06_append:glossary:n:north_atlantic_treaty_organization|North American Treaty Organization (NATO)]] require the use of [[ddsf:public:guidebook:06_append:glossary:d:data_distribution_service_dds|DDS]].

  * Enables system of systems approach (modularity and connectivity)
  * Platform agnostic
  * Mature, multi-vendor standard
  * Minimises data on the wire via [[ddsf:public:guidebook:06_append:glossary:q:quality_of_service_qos_policies|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>
{{  ddsf:public:guidebook:03_user:screen_shot_2020-12-12_at_11.43.59_am.png?700  |}}
<caption>Why (N)GVA uses DDS</caption>
</figure>

===== GVA high level architecture and benefits =====
[[ddsf:public:guidebook:03_user:07_gva| Return to Top]]
/*11:42*/

Benefits:
  * GVA [[ddsf:public:guidebook:06_append:glossary:h:hmi|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 ([[ddsf:public:guidebook:06_append:glossary:d:data_distribution_service_dds|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>
{{  ddsf:public:guidebook:03_user:screen_shot_2020-12-12_at_11.47.52_am.png?700  |}}
<caption>GVA high level architecture and benefits</caption>
</figure>

===== GVA based vehicle data architecture =====
/*13:45*/
All vehicle systems connected to the data bus using GVA [[ddsf:public:guidebook:06_append:glossary:d:data_distribution_service_dds|DDS]] are resources. They can represent something as simple as a cabin light to as complex as another subsystem with multiple components and processors

==== Resource ====
[[ddsf:public:guidebook:03_user:07_gva| 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. 

==== GVA Service Resource ====
[[ddsf:public:guidebook:03_user:07_gva| 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. 

==== Crew Intelligent Display (CID) ====
[[ddsf:public:guidebook:03_user:07_gva| 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.
 
==== Gateway Resource (J1939) ====
[[ddsf:public:guidebook:03_user:07_gva| 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.

==== GVA DDS Data Bus ====
[[ddsf:public:guidebook:03_user:07_gva| Return to Top]]

The GVA DDS data bus uses standard [[ddsf:public:guidebook:06_append:glossary:d:data_distribution_service_dds|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>
{{  ddsf:public:guidebook:03_user:screen_shot_2020-12-12_at_11.51.08_am.png?700  |}}
<caption>GVA based vehicle data architecture</caption>
</figure>

===== How GVA Makes Use of DDS (Highlights) =====
[[ddsf:public:guidebook:03_user:07_gva| Return to Top]]
/*15:31*/
  * GVA Defines Data Types
  * GVA Defines a Type Naming Convention
  * GVA Defines a Topic Naming Convention
  * GVA Defines [[ddsf:public:guidebook:06_append:glossary:d:data_distribution_service_dds|DDS]] Domain ID Allocation Rules
  * GVA Defines [[ddsf:public:guidebook:06_append:glossary:q:quality_of_service_qos_policies|QoS]] Policies
  * GVA Uses [[ddsf:public:guidebook:06_append:glossary:i:idl|IDL]] Inheritance to reduce the number of topics on the wire
  * GVA Uses [[ddsf:public:guidebook:06_append:01_family_of_standards:01_core:dds_extensible_types_dds-xtypes|X-Types]] to aid backwards compatibility between versions
  * GVA tools create IDL from the model for DDS implementation

<figure>
{{  ddsf:public:guidebook:03_user:screen_shot_2020-12-12_at_12.03.53_pm.png?700  |}}
<caption>How GVA Makes Use of DDS (Highlights)</caption>
</figure>

===== GVA data standards developed collaboratively with industry  =====
[[ddsf:public:guidebook:03_user:07_gva| Return to Top]]
/*17:09*/

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>
{{  ddsf:public:guidebook:03_user:screen_shot_2020-12-12_at_12.06.29_pm.png?700 |}}
<caption>GVA data standards developed collaboratively with industry</caption>
</figure>

===== Example Platform Independent Model (PIM) Module: Sensors =====
[[ddsf:public:guidebook:03_user:07_gva| Return to Top]]
/*17:56*/

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 [[ddsf:public:guidebook:06_append:glossary:p:pim|PIM]].

<figure>
{{  ddsf:public:guidebook:03_user:screen_shot_2020-12-12_at_12.09.31_pm.png?800|}}
<caption>Example Platform Independent Model (PIM) Module: Sensors</caption>
</figure>

===== GVA Human Machine Interface (HMI) =====
[[ddsf:public:guidebook:03_user:07_gva| Return to Top]]
/*18:15*/

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 [[ddsf:public:guidebook:06_append:glossary:h: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>
{{  ddsf:public:guidebook:03_user:screen_shot_2020-12-12_at_12.12.19_pm.png?700   |}}
<caption>GVA Human Machine Interface (HMI)</caption>
</figure>

===== GVA – the user perspective =====
[[ddsf:public:guidebook:03_user:07_gva| Return to Top]]
/*19:38*/

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 [[ddsf:public:guidebook:06_append:glossary:u:unmanned_ground_vehicle|Unmanned Ground Vehicle (UGV)]].
<figure>
{{  ddsf:public:guidebook:03_user:screen_shot_2020-12-12_at_12.15.57_pm.png?700  |}}
<caption>GVA – the user perspective</caption>
</figure>



===== What’s next? =====
[[ddsf:public:guidebook:03_user:07_gva| Return to Top]]
/*21:21*/

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 [[ddsf:public:guidebook:06_append:glossary:q:quality_of_service_qos_policies|QoS]] policies to the resources on the data bus: COTS [[ddsf:public:guidebook:06_append:glossary:d:data_distribution_service_dds|DDS]] systems connect with no modification.
  * Use [[ddsf:public:guidebook:06_append:01_family_of_standards:01_core:dds_security|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>
{{  ddsf:public:guidebook:03_user:screen_shot_2020-12-12_at_12.16.55_pm.png?700  |}}
<caption>What’s next?</caption>
</figure>


===== Slide Title =====
[[ddsf:public:guidebook:03_user:07_gva| Return to Top]]


<figure>

<caption></caption>
</figure>

/**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
/* To add a discussion page to this page, comment out the line that says 
  ~~DISCUSSION:off~~
*/
~~DISCUSSION:on|Outstanding Issues~~
~~DISCUSSION:off~~
DDS Foundation Wiki

User Tools

Site Tools

Page Tools
