Generic Vehicle Architecture – DDS at the Core.
•Descargar como PPTX, PDF•
4 recomendaciones•7,060 vistas
Presented by: Mr Keith Smith, UK GVA Office, Defence Equipment and Support, UK MOD A presentation on the progress, plans and development of the UK Generic Vehicle Architecture Programme, which underpins the integration of future UK military vehicle mission systems. The presentation will address the requirement to use DDS technology and an OMG Model Driven Architecture Approach for the data modeling aspects. It will also cover the creation of NATO GVA STANAG 4754 based on the UK GVA Approach.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Generic Vehicle Architecture – DDS at the Core.
Similar a Generic Vehicle Architecture – DDS at the Core. (20)
Más de Real-Time Innovations (RTI)
Más de Real-Time Innovations (RTI) (20)
Último
Último (20)
Generic Vehicle Architecture – DDS at the Core.
- 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?