DDS Interface Simulator for Automated Message Testing

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Testing software applications that use Real-Time Innovations Data Distribution Service (RTI DDS) requires operators to write custom programs to send and receive messages, making the process tedious and not user-friendly, especially since message domains vary greatly and require specific programming.

Innovation Solution

A DDS interface simulator using Java reflection to automate the process of sending and receiving messages, allowing operators to create a graphical user interface (GUI) without writing custom code, by generating Java message classes from IDL files and using the Test Rig to create publishers and subscribers, enabling message propagation across any domain.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If custom DDS-enabled programs are written to send and receive messages for testing, then message testing functionality is achieved, but the complexity of the testing process increases and user-friendliness deteriorates

Engineering Contradiction:

Improveuser-friendliness of testingVSAvoidcomplexity of testing process

Core Design Contradiction:

Ease of operationVSDevice complexity

Solution Approach 1:

The patent introduces an intermediary component that acts as a bridge between the test operator and the DDS system. This intermediary automatically generates the necessary publish-subscribe programs based on domain information, eliminating the need for operators to manually write custom DDS code while maintaining full testing functionality.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The system enables self-service by automatically generating the testing infrastructure. When a domain is loaded, the system autonomously creates the appropriate publish and subscribe programs, configures message routing, and sets up communication channels without requiring manual programming intervention from the operator.

Inventive Principle:

Principle #25Self-service

2Productivity

If custom programs are written for each problem domain to send and receive messages, then domain-specific message testing is achieved, but the time and effort required for testing increases

Engineering Contradiction:

Improvetesting efficiencyVSAvoidtime to set up testing

Core Design Contradiction:

ProductivityVSLoss of time

Solution Approach 1:

The system performs preliminary actions by pre-configuring domain information and message specifications before testing begins. When a domain is loaded, the system automatically generates all necessary testing infrastructure in advance, including publish-subscribe programs and message routing configurations, eliminating the need for time-consuming manual setup during actual testing.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The patent creates a universal testing framework that can handle multiple problem domains through a single interface. The system loads domain-specific information and automatically adapts the testing infrastructure to work with any domain, eliminating the need to write separate custom programs for each domain while maintaining domain-specific functionality.

Inventive Principle:

Principle #6Universality (Multi-functionality)

3Ease of operation

If a graphical interface is created to view and modify DDS messages, then ease of operation improves, but the complexity of the system increases

Engineering Contradiction:

Improveability to view and modify messagesVSAvoidsystem architecture complexity

Core Design Contradiction:

Ease of operationVSDevice complexity

Solution Approach 1:

The patent replaces manual programming operations with an automated graphical interface system. Instead of requiring operators to manually write and configure code, the system provides visual tools for viewing, creating, and modifying message specifications, automatically translating these visual operations into the appropriate DDS configurations and code generation.

Inventive Principle:

Principle #28Mechanics substitution (Replace mechanical system)

Data Source

PatentUS9015672B2Interface simulator for test rig in data distribution service

Publication Date: 2015.04.21 THE UNITED STATES OF AMERICA AS REPRESENTED BY THE SECRETARY OF THE NAVY

AI summary

A method of interface simulation is provided for enabling publication and subscription of messages for a given problem domain, without requiring development of software or code. The method includes identifying a set of messages using the DDS as a problem domain; generating said .java message class from said problem domain generated from a .idl file for Interface Definition Language (IDL); processing said .java message class by Java reflection; generating a plurality of .java message stubs generated in the IDL format of said problem domain; incorporating said plurality of .java message stubs into a .jar message class file by said Java reflection; and rendering a graphical display that enables an operator to select and edit a .java message object from said plurality of stubs in said .jar message class.