Host Instrument Command Interpreter for Non-Native Protocol Emulation

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing systems for emulating remote command sets on host instruments require frequent firmware updates and consume significant memory, leading to performance issues and compatibility challenges due to the need for duplicating command logic and responding to various command sets, especially when adapting to new instruments or changes in command sets.

Innovation Solution

Implementing a programmable interpretation parser in the host instrument that supports external command interpretation rules, allowing for the translation of non-native commands and responses without altering the firmware, enabling the host instrument to emulate alternate instruments without the need for constant firmware updates.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If a command parser is created to support all command rules of the emulated instrument, then the host instrument can respond to commands in the same way as the emulated instrument, but the host instrument must obtain new firmware revisions to support changes to the emulated instrument

Engineering Contradiction:

Improvecommand emulation accuracyVSAvoidfirmware update frequency

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The patent separates the command interpretation logic from the firmware by implementing it as an external script or program that can be independently updated. The host instrument's firmware remains stable while the command interpretation layer is segmented into updatable modules that can be downloaded and executed without firmware reconfiguration.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The command interpretation system is made dynamic by allowing the host instrument to load, execute, and update interpretation rules at runtime. Instead of static firmware-coded parsers, the system dynamically loads external scripts that define command mapping rules, enabling flexible adaptation to different emulated instruments without firmware changes.

Inventive Principle:

Principle #15Dynamics

2Adaptability or versatility

If a command parser supports all command rules of multiple alternate instruments, then the host instrument can emulate various instruments, but it consumes a significant amount of internal instrument memory

Engineering Contradiction:

Improveinstrument emulation capabilityVSAvoidinternal memory consumption

Core Design Contradiction:

Adaptability or versatilityVSQuantity of substance

Solution Approach 1:

The patent extracts the command interpretation logic from the host instrument's internal memory and stores it externally. The interpretation rules are kept in external files or databases that can be loaded into memory only when needed for specific emulation tasks, significantly reducing the permanent memory footprint of the host instrument.

Inventive Principle:

Principle #2Taking out (Extraction)

Solution Approach 2:

The host instrument implements a universal command interpretation engine that can handle multiple instrument types through a single flexible parser. Instead of having separate hard-coded parsers for each instrument, one universal engine dynamically loads appropriate interpretation rules based on the target instrument, eliminating redundant code and memory usage.

Inventive Principle:

Principle #6Universality (Multi-functionality)

3Adaptability or versatility

If multiple command parsers are implemented to emulate different instruments, then the host instrument can support various command sets, but the performance of parsing standard native commands is adversely impacted

Engineering Contradiction:

Improvecommand set supportVSAvoidcommand parsing performance

Core Design Contradiction:

Adaptability or versatilityVSProductivity

Solution Approach 1:

The patent introduces an intermediary command interpretation layer that sits between the incoming commands and the host instrument's native command processor. This intermediary layer translates non-native commands to native commands using external rule sets, allowing the native command parser to remain optimized and unchanged while still supporting multiple instrument protocols through the translation layer.

Inventive Principle:

Principle #24Intermediary (Mediator)

4Adaptability or versatility

If the host instrument emulates an alternate instrument, then system automation can function with the host instrument instead of the emulated instrument, but the manufacturer of the host instrument may not be informed of changes to commands for the emulated instrument

Engineering Contradiction:

Improveemulation compatibilityVSAvoidcommand change information

Core Design Contradiction:

Adaptability or versatilityVSLoss of information

Solution Approach 1:

The host instrument implements self-service capability by automatically downloading updated command interpretation rules from external sources. When command sets for emulated instruments change, the host instrument can autonomously retrieve updated interpretation scripts or configurations without requiring manual intervention or notification from the manufacturer, maintaining up-to-date emulation compatibility.

Inventive Principle:

Principle #25Self-service

Data Source

PatentUS9052934B2Remote command interpreter

Publication Date: 2015.06.09 FLUKE CORP

AI summary

A host instrument is disclosed that is capable of supporting non-native command sets. The host instrument uses interpretation rules to translate a non-native command into one or more actions. The host instrument also uses the interpretation rules to determine the appropriate responses to be transmitted, if any. The actions and responses of the host instrument emulate those of an alternate instrument that supports the command set.