Vehicle Bus Virtual Channel Server Process
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing methods for controlling data transmission of virtual buses in vehicular software development require rebooting the computer, have poor portability across different operating systems, and lack automatic update capabilities to support new bus types.
Innovation Solution
A method and system for implementing a vehicle bus virtual channel using a server process and client processes that communicate via UDP ports, allowing for registration, heartbeat maintenance, and message transmission with timestamping and direction attribute modification.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a driver program is written to control data transmission of virtual buses at the bottom layer, then real-time communication between bus tool processes can be achieved, but the system requires rebooting to become usable and has poor portability across different operating systems
Solution Approach 1:
The patent introduces a socket-based communication layer as an intermediary between the driver program and bus tool processes. This socket layer handles data transmission using standard TCP/IP protocols, allowing the system to maintain real-time communication capabilities while eliminating the need for rebooting and improving portability across different operating systems. The socket layer acts as a mediator that translates between the low-level driver operations and high-level application requirements.
Solution Approach 2:
The patent replaces the traditional driver-program-dependent mechanical system with a socket-based network communication system. Instead of relying on operating system-specific driver interfaces that require rebooting, the system uses universal socket communication that can operate across different platforms without restart, substituting the rigid driver-model with a flexible network-communication model.
2Reliability
If a driver program is used to control virtual bus data transmission, then communication can be established, but the system lacks automatic update capabilities to support new bus types
Solution Approach 1:
The patent implements a dynamic configuration system where bus parameters and communication protocols can be updated in real-time without requiring system reboot or driver reinstallation. The socket-based architecture allows new bus types to be added by simply registering new communication handlers, making the system adaptable and flexible rather than static and rigid.
Solution Approach 2:
The patent creates a universal communication framework using sockets that can handle multiple bus types through a common interface. Instead of requiring separate driver programs for each bus type, the system uses a single socket-based infrastructure that can accommodate different bus protocols and types through configurable parameters and plug-in handlers, providing multi-functionality and ease of adaptation.
3Reliability
If driver programs are written for specific operating systems, then communication control is achieved, but portability across different operating systems deteriorates
Solution Approach 1:
The patent substitutes operating system-specific driver mechanisms with a universal socket-based communication system. Sockets provide a standardized interface that works across different operating systems (Windows, Linux, macOS) without requiring OS-specific driver installation, thereby maintaining reliable communication control while dramatically improving portability and cross-platform compatibility.
Data Source
Figure 1
Figure 2~3
Figure 4
AI summary
Provided is a system for implementing a vehicle bus virtual channel, comprising: at least one computer device, configured to execute client processes and a server process; wherein, the client processes are configured to send a registration request data packet to the server process, send a heartbeat packet to the server process at a specific time interval, and send a vehicle bus message to the server process; the server process is configured to: receive the registration request data packet, the heartbeat packet, and the vehicle bus message from a client process, set a timestamp of the vehicle bus message and send the vehicle bus message back to the client process while modifying a direction attribute of the vehicle bus message to "sent"; at the same time, send the vehicle bus message to other client processes and modify the direction attribute of the vehicle bus message to "received".