Portable Distributed Application Framework for Router Protocol Testing

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current router testing systems require extensive hard-coding and customization for each new protocol, leading to complex and costly maintenance, especially due to the need for unique graphical user interfaces and extensive application programming interfaces (APIs), which complicates the process of adapting to new or modified protocols.

Innovation Solution

A generic protocol framework that uses external definition files to interface with and control protocol emulations, allowing for a generic graphical user interface, control, and command host component, and protocol housing on embedded devices, enabling support for multiple protocols without the need for extensive reworking of the framework or custom code.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If hard-coding is used for each protocol implementation, then protocol-specific functionality is achieved, but system complexity and maintenance cost increase significantly

Engineering Contradiction:
Improveprotocol support capabilityVSAvoidcode complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent implements a universal protocol handler that can process multiple protocols through a single interface. The handler uses configuration files to define protocol-specific behaviors while maintaining a common processing framework, allowing one component to serve multiple protocol functions without requiring separate hard-coded implementations for each protocol.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The patent uses configuration files that serve as templates or copies of protocol specifications. These files contain protocol definitions that can be loaded and instantiated without modifying the underlying code, allowing protocol behavior to be copied and adapted through configuration rather than through creating new code for each protocol.

Inventive Principle:
Principle #26Copying

2Ease of operation

If unique graphical user interfaces are created for each protocol, then protocol-specific control is achieved, but development time and maintenance effort increase

Engineering Contradiction:
Improveprotocol-specific controlVSAvoiddevelopment time
Core Design Contradiction:
Ease of operationVSLoss of time

Solution Approach 1:

The patent implements a single graphical user interface that can control multiple protocols through a unified design. The GUI uses the same configuration files and handler mechanisms to adapt its behavior based on the selected protocol, eliminating the need to create and maintain separate GUI implementations for each protocol while still providing protocol-specific control capabilities.

Inventive Principle:
Principle #6Universality (Multi-functionality)

3Adaptability or versatility

If extensive APIs are developed for each protocol, then protocol functionality is accessible, but API maintenance becomes prohibitively expensive

Engineering Contradiction:
Improveprotocol functionality accessVSAvoidmaintenance cost
Core Design Contradiction:
Adaptability or versatilityVSEase of repair

Solution Approach 1:

The patent extracts protocol-specific logic from the API layer and places it in configuration files. The API itself becomes protocol-agnostic, containing only the common interface definitions and processing logic. Protocol-specific behaviors are extracted into external configuration files that can be modified without touching the API code, significantly reducing maintenance costs.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent introduces configuration files as an intermediary layer between the API and protocol implementations. This intermediary allows the API to remain stable and simple while protocol-specific details are handled through the configuration layer, reducing the complexity and maintenance burden of the API itself.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS7467078B2Portable distributed application framework
Publication Date: 2008.12.16 KEYSIGHT TECH SINGAPORE (SALES) PTE LTD
  • US7467078B2 patent drawing
  • US7467078B2 patent drawing
  • US7467078B2 patent drawing

AI summary

A portable distributed application framework that uses a definition file describing a structure of data and commands to be used by the framework to interface with an application. A proxy, responsive to a definition file, creates and receives messages based on the definition file. The created messages contain data and commands used to control the application while the received messages contain data from the application. A control, responsive to the definition file, relays messages between the proxy and the application. A housing, responsive to the definition file and the messages from the proxy, provides the application with configuration information and receives data from the application.