In-Vehicle Gateway Non-Standard Protocol Loading
Find Innovative SolutionsGenerate 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
Engineering 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
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).
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.
2Device complexity
If standard Internet protocols are used, then system simplicity is improved, but communication efficiency and flexibility deteriorate
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.
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.
3Adaptability or versatility
If non-standard transfer protocol modules are loaded dynamically, then communication flexibility is improved, but device complexity increases
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.
Data Source
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.


