1.
Generic Vehicle Architecture
(DDS at the Core)
Keith Smith
GVA Office
Land Equipment, DE&S
Mark Ollerton
Land Systems
QinetiQ

2.
Agenda
• Challenges
• Open Systems – Land Open Systems
Architecture
• Generic Vehicle Architecture (GVA)
• Land Data Model
• GVA Data Model Development Facility –
QinetiQ
• Questions?

3.
Challenges
• Army 2020 requires agile and adaptive
forces able to be configured and equipped
for specific operations
• User needs and technology advancing
faster than projects can deliver
• System of Systems Capabilities required -
increasing number of connections required
between systems
• Unplanned integrations required (UORs)
• Pressure to reduce the cost of ownership
Open Systems Approaches seen as part of the solution

4.
Systems of Systems Approach (SOSA)
• JSP906 Directive - Defence Principles for Coherent
Capability
– Principle 1: Unify Defence
– Principle 2: Drive Operational and Business Effectiveness
– Principle 3: Minimise Diversity
– Principle 4: Develop and Deliver for Reuse
– Principle 5: Choose Proven Ways and Means First
– Principle 6: Ensure Commonality of Service Provision across Defence
– Principle 7: Develop and Deliver Capability for Flexibility, Adaptability
and Interoperability
– Principle 8: Use Open Standards and Approaches

5.
Land Open Systems Architecture
• LOSA is the UK MODs approach for Open
Systems across the Land Environment
• LOSA is aligned with the JSP906 Directive -
Defence Principles for Coherent Capability
• The LOSA strategy endorsed by Army Board
covers
– Governance of the Land Environment
– Open Architecture Approaches (GVA, GBA, GSA, COI(L))

6.
JointDomains/DefenceAuthorities
Environments
Maritime Land Air
Land Environment
Authority
C4ISR
Logistics
Personnel (including all training and education)
Information
CAPABILITY
OPERATIONAL
TECHNICAL
LOSA
Capability Coherence
Health, Safety and Environmental Protection
LOSA Context

7.
LOSA Aims
• Improved operational effectiveness:
– Rapid response to changing situations.
– Reduced training burden.
– Increased platform availability.
– Improved interoperability and easier system
management.
• Reduced cost of ownership:
– Faster, simpler, and cheaper procurement.
– The ability to procure heterogeneous, multi-
vendor open systems.
– Easy to upgrade.
– Reduced TL costs.
– Prevents proprietary lock-in.
– Return control to MOD.

8.
Common Open Interface (Land)
(COI(L))
Land Open Systems Architectures
Generic
Vehicle
Architecture
(GVA)
Generic
Base
Architecture
(GBA)
Generic
Soldier
Architecture
(GSA)
Other Domains:
Maritime
Air
Joint Enablers:
Coalition and NGOs
Civil Emergency Services
OGDs
•C4ISR
•Weapons
•Logistics
•Training
Def Stan 23-09
GVA
Def Stan 23-13
GBA
Def Stan 23-12
GSA
Def Stan 23-14
COI(L)
Defence Standards, Joint Service Publication
and Joining Rules
LOSA Architectures and Standards
Standards are not a design!
External Standards
and Rules

9.
GVA (Def Stan 23-09) KEY
REQUIREMENTS
Generic Vehicle Architecture

10.
Vehicle Programme
Foxhound
Warrior CSP
Challenger 2 LEP
Scout SV
MRV-P
F-ATV
FPBA
LPMR
MIV
(Representative images only)

11.
GVA (Def Stan 23-09) KEY
REQUIREMENTS• Use of a standardised, multifunctional, Crew
Control & Display (“One Glass”, “One Headset”)
• Use of a Ethernet LAN
• Use of DDS/DDSi as the data distribution protocol
• Use of the Land Data Model/GVA Data Model.
• Use of Def Stan 00-82 for platform video
distribution
• Use of Def Stan 61-5 for power distribution
• Standardised Power and Data connectors
Key GVA Features

12.
Land Data Model & Model
Driven Architecture

13.
Land Data Model – Why?
• Single coherent view of the data required to support
operation of systems in the Land Environment
– Open up system data interfaces
– Reduce bespoke system data implementations
– Improve our ability to add new systems
– Facilitate data infrastructure and data services sharing
– Improve data interoperability
– Enable an evolutionary acquisition approach
– Reduce through life cost of change
Along with DDS is key to getting GVA benefits

14.
Land Data Model –What is it?
• Approach to the creation and management of
a set of enduring, re-useable data definitions
• It Includes:
– Modelling Methodology
– Single Controlled Model Repository
– Model Driven Architecture (MDA) toolchain
– Repository governance and change control

15.
OMG Model Driven Architecture
The OMG Model Driven Architecture embeds three key
principles:
Domain Partitioning of the System
Platform Independent Modelling of each Domain
Automated Generation of the Platform Specific
Implementation
These principles are designed to achieve specific goals:
Model longevity through platform independence
Component Reuse through pollution control
Portability through layered architecture
Courtesy of Abstract Solutions

16.
MDA Approach
Platform Specific
Implementation
(IDL)
Platform
Independent Model
Platform
Specific Model
Translator
Used to configure DDS
Software operation
Technology
Agnostic
Model
Automatically
Generated IDL
All Models and Support Tools are “Open”

17.
Re-Use of PIMs
The PIM domains can
be reused in multiple
installations…
Platform Independent Models
ECM
Water Engine
HUMS
Portable
Charger
Navigation
Radar
Base PSM
Generate Base
PSM
Lean Services
JSON
Water HUMS
Soldier PSM
Generate
Soldier PSM
Lean Services
Message Protocol
ECM
HUMS
Portable
Charger
Navigation
Vehicle PSM
Generate
Vehicle PSM
DDS
IDL
Engine HUMS
Navigation RadarECM
…and implemented on
multiple deployment
architectures

18.
LDM Modelling Methodology
• Tailored methodology based on UML
• Pioneered by Abstract Solutions
• Key Parts
– Domains and Domain Partitioning
– System Use Case Diagrams – Requirement capture
– UML Class Models – Information and Data content
– UML Sequence Diagrams – Interactions between
components
– UML State Models – Behaviour and system modes
• Documented and published as “open”– End Nov 15.

19.
Repository
ECM
ECM
ECM
ECM
ECM
ECM
ECM
ECM
ECM
Alarms
ECM
ECM
ECM
Video
ECM
Engine
Navigation
ECM
ECM
ECM
Mount
ECM
ECM
ECM
ECM
Fusion
ECM
ECM
ECM
UGV
PIMs and Build Sets
GVA Build Set
V3.6
??? Build Set
V1.0
??? Build Set
V1.6

20.
NATO GVA STANAG 4754
• NATO Approach to Open Systems
• STANAG 4754 in NATO review now
• Based on UK GVA
• Broader scope than UK GVA
• Adopts DDS and the Land Data Model

21.
© QinetiQ Limited 2015
GVA Data Model Development Facility
Mark Ollerton
Open Architectures Group
Land Systems
RTi Conference
Heathrow, London
14th-15th Oct 2015
25

22.
© QinetiQ Limited 2015
Why do we do GVA?
• Industry
• Want to make system integration less risky, cheaper
• Want to open up new markets
• MoD
• Want to make equipment programmes, updates, maintenance, technology insertion cheaper
• Want agility in the composition of vehicle systems – react to change
26

23.
© QinetiQ Limited 2015
Why the GVA Data Model?
Interoperability:
• The GVA DM forms the top level of the GVA ICD
• The bit that allows GVA applications talk to each other, and maybe later, Inter
Process Communications
• It de-couples GVA system device implementations from each-other
• It’s the domain specific bit of GVA
• Everything else is covered by standard COTS HW/SW components
27

24.
© QinetiQ Limited 2015
Why the Data Model Development Facility ?
• Need a place to validate new data model elements
• Need a place to experiment and develop common platform services
• Infrastructure and Application services that are assumed to be provided by the core GVA fit
• Need a place to investigate specific engineering questions, e.g. interoperability
• Can be linked to our other rigs for multi-protocol investigations, e.g. :
• DefStan 00-82 - Video & Audio
• IEEE1588 Precision Time Protocol – System Synchronisation
• SAE AS6802 Time Triggered Ethernet, IEEE 802.1 AVB (Audio-Video Bridging), IEEE 802.1 TSN
(Time-Sensitive Networking) - Safety
• Can add further components for multi-domain investigations, e.g.:
• Data Guards & Gateways – Security & Safety partitioning
28

25.
© QinetiQ Limited 2015
What does it look like?
29

26.
© QinetiQ Limited 2015
What have we done so far?
• Built up some PCs around a switch, with RTi stacks and development environment
• Got it going with Shapes Demo
• Replaced Demo with software emulations of AFV devices and GUI
• Developed application software on RTi API
• Generated GVA Readers and Writers from GVA IDL using vendor tools
• Developed and validated GVA Resource ID mechanism and Registry
• Documented and ratified by GVA TWG
30

27.
© QinetiQ Limited 2015
What have we done so far?
• Built up interoperability PC configurations
• DDS Stacks from:
• RTi (Connext)
• TwinOaks (CoreDX)
• PrismTech (Vortex OpenSplice)
• OCI (OpenDDS)
• Mounted on Linux and Windows platforms
• Used Vendor tools to generate Readers & Writers from GVA IDL
• Looking to investigate potential interoperability issues between vendors
• Very important to MoD & Industry
• Developing GVA Resource Configuration mechanism and manager
• Will develop further common platform services
31

28.
© QinetiQ Limited 2015
We need to study Interoperability:– some setup issues
• Different vendor’s tools expect the IDL files in a specific format, one example is the
IDL key definitions:
a) PrismTech use #pragma keylist
b) TwinOaks use #define DDS_Key
c) RTI use @key notation
d) OpenDDS use #pragma DCPS_DATA_KEY
• On certain occasions shapes published on OCI’s shapes demo application cannot be
viewed on PrismTech’s shapes demo app and vice versa
• Closing the TwinOaks shapes demo application causes the OpenDDS’s shapes
application to crash
• PrismTech does not allow composite keys – keys as structs
• Compatibility of bounded data types between RTI and TwinOaks e.g. string<20>
• Use of 'get _type_name()’ in TwinOaks does not return the same type name as 'get
_type_name()’ in RTI
32

29.
© QinetiQ Limited 2015
We need to study Interoperability
• More complex mechanisms
• QoS
• Filtering
• Less established features
• X-Types
• Security
• Specialisations
• Safety capable configurations
33

30.
Contact:
Spruce 2c #1216
MOD Abbey Wood
Bristol BS34 8JH
desledefstans@mod.uk
030 679 37843
https://landopensystems.mod.uk
Questions?