In-Vehicle Gateway Non-Standard Protocol Loading

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional telematics systems rely on standard Internet protocols (HTTP-over-TCP-over-IP) for data exchange between vehicles and remote client devices, which limits flexibility and efficiency in communication protocols.

Innovation Solution

Implementing a non-standard transfer protocol module that allows the in-vehicle communications gateway module to establish a connection with a remote server using a non-standard protocol, enabling data exchange without relying on standard Internet protocols, by loading a software component with a non-standard transfer protocol stack and using alternative communication protocols.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If standard Internet protocols (HTTP-over-TCP-over-IP) are used for data exchange, then compatibility and ease of implementation are improved, but communication flexibility and efficiency deteriorate

Engineering Contradiction:
Improveease of implementationVSAvoidcommunication flexibility
Core Design Contradiction:
Ease of operationVSAdaptability or versatility

Solution Approach 1:

The gateway module dynamically loads software components containing non-standard transfer protocol stacks at runtime based on communication requirements. This dynamic loading mechanism allows the system to adapt its communication protocol stack from standard to non-standard protocols as needed, resolving the contradiction between ease of implementation (using standard protocols by default) and communication flexibility (switching to non-standard protocols when required).

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The system changes the protocol parameter by loading different software components with different transfer protocol stacks. When non-standard protocols are needed, the gateway loads a software component containing a non-standard transfer protocol stack, thereby changing the communication parameter from standard to non-standard without altering the hardware or basic system architecture.

Inventive Principle:
Principle #35Parameter changes

2Device complexity

If standard Internet protocols are used, then system simplicity is improved, but communication efficiency and flexibility deteriorate

Engineering Contradiction:
Improvesystem simplicityVSAvoidcommunication efficiency
Core Design Contradiction:
Device complexityVSProductivity

Solution Approach 1:

The communication protocol functionality is segmented into separate loadable software components. The gateway module maintains a simple core structure while allowing protocol-specific functionality to be segmented into distinct software components that can be loaded only when needed. This segmentation resolves the contradiction by keeping the base system simple while enabling efficient non-standard protocol communication when required.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The gateway module is designed with universal functionality to support both standard and non-standard transfer protocols through a common architecture. It can universally handle data exchange using either standard Internet protocols or non-standard protocols by loading appropriate software components, thereby achieving multi-functionality without increasing inherent system complexity.

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

3Adaptability or versatility

If non-standard transfer protocol modules are loaded dynamically, then communication flexibility is improved, but device complexity increases

Engineering Contradiction:
Improvecommunication flexibilityVSAvoiddevice complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The system performs preliminary action by pre-compiling non-standard transfer protocol stacks into separate software components during the build process. These pre-compiled components are then loaded dynamically at runtime based on communication needs. This preliminary preparation resolves the contradiction by organizing complexity into reusable, pre-processed units that simplify runtime operations while maintaining communication flexibility.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS7849224B2Method and apparatus for implementing a mobile server
Publication Date: 2010.12.07 GM GLOBAL TECHNOLOGY OPERATIONS LLC
  • US7849224B2 patent drawing
  • US7849224B2 patent drawing
  • US7849224B2 patent drawing

AI summary

Methods and apparatus are provided for transmitting data from remote server device to a computer module in a vehicle. A request for data is transmitted from the computer module over an in-vehicle network to an in-vehicle communications gateway module. The request for data from the computer module is destined for a remote server device. A request for a software component is transmitted from a standard port of the in-vehicle communications gateway module to the remote server device. The software component comprises a non-standard transfer protocol module. The in-vehicle communications gateway module loads the non-standard transfer protocol module, and the remote server device transmits the requested data to the in-vehicle communications gateway module according to the non-standard transfer protocol. The in-vehicle communications gateway module then transmits the requested data (provided from the remote server device) to the computer module over the in-vehicle network.