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?