GVA & DDS: How to Speed Up Development Using RTI Prototyper

rti-blog-post-image-2018-11-15-gva-dds-prototyper-642x396-1118

The traditional approach to designing a land platform system – composed of standalone subsystems – is laborious and challenging for developers and integrators. The design often includes stove-pipe upgrades with numerous integration conflicts, countless control and display panels, suboptimal exploitation of available data, degraded training capability and unending maintenance issues – all of which leads to major delays and significantly higher costs. The solution is to build military equipment based on open standards such as DDS, leading to flexible and interoperable systems that work well when deployed in different operation environments and configurations.

The Ground Vehicle Architecture (GVA) – including all its branches NATO-GVA, UK-GVA, Australia-GVA – and its Land Data Model (LDM) share a common goal: provide an Interoperable Open Architectures (IOA) able to integrate multiple land subsystems. In order to achieve this goal, GVA selected the Object Management Group (OMG) Data Distribution Service™ (DDS) standard as its core connectivity bus providing an interoperable wire protocol (RTPS) and an API standard for data-centric connectivity. Together they provide a flexible, military-grade standard foundation to implement the GVA approach.

null

NATO-GVA Architecture (source)

RTI Prototyper with Lua speeds up GVA development and integration by easily creating a GVA-compliant subsystem prototype, such as a GVA-complaint GPS prototype. Here’s how.

Building GVA-Compliant Subsystem Prototypes with RTI Prototyper

DDS_Image

RTI Connext DDS Professional provides numerous tools that come in handy in the development phase of any subsystem that is part of a distributed system. Developing a GVA-compliant subsystem, such as a weapon control system, can be a cumbersome and time-consuming task. It’s even more difficult to integrate one subsystem with another that only exists on paper or is being developed by a different team. Building a basic prototype of any subsystem that needs to be integrated (such as a GVA-compliant GPS) can greatly assist in overcoming this hurdle, right from the beginning of the subsystem development process. Such a prototype can be easily built using RTI Prototyper, a Lua-based scenario testing engine. Here’s a step-by-step example of how to build the prototype.

GVA GPS Prototype Example

In order to build a GVA-DDS prototype with RTI Prototyper, two files are required:

1) The components definition which is composed of types, QoS definition and DDS entities (e.g., Data-Writers).

2) The prototype’s logic which defines when and what to publish according to each one of its built-in triggers (e.g., time-based, data input-based, etc.) using a Lua scripting language.

XML Component Definition

Within the RTI Tools Suite, a prototype mockup is defined using the RTI XML-Based Application Creation (XML App) file format, which describes the whole system via an XML file. Use the Prototyper’s XML App engine to automatically instantiate and run the prototype defined in it.

XML App file format

The XML App file format is composed of four separate sections which together define the whole subsystem.

1) QoS definition: As of today, the GVA standard doesn’t explicitly define specific QoS settings. In this example, we will use the default QoS values.

2) Type definition: The NGVA Navigation Module, for instance, defines two IDL files: LDM_Common.idl and Navigation_Reference_PSM.idl. Take these files and convert them to XML format using the RTI CodeGenerator. There are two ways:

a. Via GUI

 null

b. Command line:

%NDDSHOME%/bin/rtiddsgen” -convertToXml LDM_Common.idl

Note we need to do the same process for Navigation_reference_PSM.idl. These files will not be provided as part of this example.

3) Domain_library: Defines which domain is used and which types and topics are registered in it. For the GPS prototype, we will need to select the type P_Navigation_Reference_PSM::C_Position from Navigation_Reference_PSM.xml and define it as topic C_Position.

4) Participant_library: Defines the DDS Entities composing the GVA subsystem we are creating. In this example, we will create a DataWriter for the C_Position topic, plus all necessary entities around it.

You can find this example in NGVA_Prototyper_DDS_Simulator.xml; it looks like this:

<dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"    
xsi:noNamespaceSchemaLocation="http://community.rti.com/schema/5.3.1/rti_dds_profiles.xsd" version="5.3.1">  
<!-- QoS Definition -->  
<qos_library name="DefaultLibrary">    
<qos_profile name="DefaultProfile" is_default_qos="true">    
</qos_profile>  
</qos_library>  
<!-- Types Definition-->  
<types>    
<include file="Navigation_Reference_PSM.xml"/>    
<include file="LDM_Common.xml"/>  
</types>  
<!-- Domain Library -->  
<domain_library name="GVADomainLibrary">    
<domain name="NavigationModuleDomain">      
<register_type name="P_Navigation_Reference_PSM::C_Position"                   type_ref="P_Navigation_Reference_PSM::C_Position" />      
<topic name="C_Position"               
register_type_ref="P_Navigation_Reference_PSM::C_Position"/ </domain>  
</domain_library>  
<!-- Participant library -->  
<domain_participant_library name="GVAParticipantLibrary">    
<domain_participant name="GVANavigationSimulator"               
domain_ref="GVADomainLibrary::NavigationModuleDomain">      <publisher name="Publisher">        
<data_writer name="C_Position_Writer" topic_ref="C_Position"/>      </publisher>    
</domain_participant>  
</domain_participant_library>
</dds>

Lua Logic Definition

Once the prototype is designed in XML, we create its logic using a Lua scripting language. Each cycle, RTI Prototyper will run the script provided as input. In this case, we will select an initial position (e.g. RTI HQ location) and create a path around it by assigning nGVA-compliant positions data to the C_Position Topic.

local C_Position_Writer = CONTAINER.WRITER['Publisher::C_Position_Writer']
local C_Position_Instance = C_Position_Writer.instance
if count then count = count + 1
else -- initialize (first time)
count = 0
latCenter = 37.410436
lonCenter = -122.016126
radius = 0.0005
end

-- Set fields values
C_Position_Instance['A_timeOfDataGeneration.A_second'] = os.time()
C_Position_Instance['A_currentPosition.A_latitude'] = math.rad(latCenter + radius * math.sin(count/10))
C_Position_Instance['A_currentPosition.A_longitude'] = math.rad(lonCenter + radius * math.cos(count/10))
C_Position_Instance['A_currentPosition.A_altitude'] = 3 + math.random()

-- write instance
C_Position_Writer:write()

Bringing it All Together

Now that we have all the pieces, we just need to run the prototype via the Prototyper UI or via a command line.

a. Via GUI

RTI DDS PrototyperEX

b. Command line

%NDDSHOME%\bin\rtiddsprototyper.bat -cfgName GVAParticipantLibrary::GVANavigationSimulator -cfgFile GVA_Prototyper_DDS_Simulator.xml -domainId 1 -period 1 -luaFile SimulatorLogic.lua -luaOnStart false -luaOnData false -luaOnPeriod true -luaOnStop false

The prototype logic provides a very simple circular route around RTI’s HQ. If we just plot the positions in Google Maps, we could see the result below. But you can implement any route or change the origin, or any other ideas you may have. We invite you to play around with the example.

null
 

While this “5-minute” prototype might not provide a real-life simulation, it illustrates how to reduce and facilitate integration of any sub-system just by having the XML definition of the system. We invite you to take a look at System Designer, still in the experimental stage, for a graphical tool to build and maintain your system’s XML definitions.

Getting Started with Connext DDS

Connext® DDS is the world's leading implementation of the Data Distribution Service (DDS) standard for Real-Time Systems. Try a fully-functional version of Connext DDS 5.3 for 30 days.


Free Trial