Generic Vehicle Architecture – DDS at the Core.

Generic Vehicle Architecture(DDS at the Core)

Keith SmithGVA Office

Land Equipment, DE&S

Mark OllertonLand Systems

QinetiQ

Agenda• Challenges• Open Systems – Land Open Systems

Architecture• Generic Vehicle Architecture (GVA)• Land Data Model• GVA Data Model Development Facility –

QinetiQ• Questions?

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

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

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))

Join

t Dom

ains

/ D

efen

ce A

utho

ritie

s

Environments

Maritime Land AirLand EnvironmentAuthority

C4ISR

Logistics

Personnel (including all training and education)

Information

CAPABILITYOPERATIONAL

TECHNICAL

LOSA

Capability Coherence

Health, Safety and Environmental Protection

LOSA Context

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.

Savings

Common Open Interface (Land)(COI(L))

Land Open Systems Architectures

GenericVehicle

Architecture(GVA)

GenericBase

Architecture(GBA)

GenericSoldier

Architecture(GSA)

Other Domains:

MaritimeAirJoint Enablers:

Coalition and NGOsCivil Emergency Services

OGDs

•C4ISR•Weapons•Logistics•Training

Def Stan 23-09GVA

Def Stan 23-13GBA

Def Stan 23-12GSA

Def Stan 23-14COI(L)

Defence Standards, Joint Service Publication and Joining Rules

LOSA Architectures and Standards

Standards are not a design!

External Standards and Rules

GVA (Def Stan 23-09) KEY REQUIREMENTS

Generic Vehicle Architecture

Vehicle Programme

Foxhound

Warrior CSP

Challenger 2 LEP

Scout SV

MRV-P

F-ATV

FPBALPMRMIV

(Representative images only)

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

Land Data Model & Model Driven Architecture

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

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

OMG Model Driven ArchitectureThe OMG Model Driven Architecture embeds three key principles:

Domain Partitioning of the SystemPlatform Independent Modelling of each DomainAutomated Generation of the Platform Specific Implementation

These principles are designed to achieve specific goals:Model longevity through platform independenceComponent Reuse through pollution controlPortability through layered architecture

Courtesy of Abstract Solutions

MDA Approach

Platform Specific Implementation

(IDL)

Platform Independent Model

PlatformSpecific Model

Translator

Used to configure DDS Software operation

TechnologyAgnostic

Model

Automatically Generated IDL

All Models and Support Tools are “Open”

Re-Use of PIMsThe PIM domains can be reused in multiple

installations…

Platform Independent Models

ECM

Water Engine

HUMS

PortableCharger

Navigation

Radar

Base PSM

Generate Base PSM

Lean Services

JSON

Water HUMS

Soldier PSM

Generate Soldier PSM

Lean Services

Message Protocol

ECM

HUMSPortableCharger

Navigation

Vehicle PSM

Generate Vehicle PSM

DDS

IDL

Engine HUMS

Navigation RadarECM

…and implemented on multiple deployment

architectures

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.

Repository

ECMECM

ECMECM

ECMECM

ECM

ECMECM

Alarms

ECMECM

ECMVideo

ECMEngine

Navigation

ECMECM

ECMMount

ECMECM

ECMECM

Fusion

ECMECM

ECMUGV

PIMs and Build SetsGVA Build Set

V3.6

??? Build Set

V1.0

??? Build Set

V1.6

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

© QinetiQ Limited 2015

GVA Data Model Development Facility

Mark OllertonOpen Architectures GroupLand Systems

RTi ConferenceHeathrow, London14th-15th Oct 2015

25

© 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

© 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

© 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

© QinetiQ Limited 2015

What does it look like?

29

© 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

© 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

© 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

© QinetiQ Limited 2015

We need to study Interoperability

• More complex mechanisms• QoS• Filtering

• Less established features• X-Types• Security

• Specialisations• Safety capable configurations

33

Contact:Spruce 2c #1216MOD Abbey WoodBristol BS34 [email protected] 679 37843

https://landopensystems.mod.uk

Questions?