Method and system for implementing vehicle bus virtual channel

Abstract

To provide a method for implementing a vehicle bus virtual channel, which belongs to the field of vehicle software development techniques.SOLUTION: A client process sends a registration request packet to a server process, and after successfully receiving the registration request packet, the server process gives feedback to the client process that a signal has been successfully received. After receiving the feedback, the client process sends a heartbeat packet to the server process at a specific interval, and the server process waits for a response to the heartbeat packet. The client process sends a vehicle bus message to the server process.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] This application claims priority from Chinese Patent Application No. 2023114028853, filed on October 26, 2023, and U.S. Patent Application No. 18 / 380,187, filed on October 15, 2023, the entire contents of which are hereby incorporated by reference.

[0002] The present invention relates to the technical field of vehicle software development, and more particularly to a method and system for implementing a vehicle bus virtual channel. [Background technology]

[0003] To realize the communication process of simulating various automotive buses on a computer, virtual hardware support is provided to the bus tool, and multiple bus tool processes are connected by virtual hardware to enable real-time communication. In conventional vehicle software development technology, it is common to create a driver to control data transfer on the virtual bus at a lower level of the system. Summary of the Invention

[0004] The present invention relates to a method for realizing an automobile bus virtual channel, the method including: Designing and launching a single-instance server process, and then listening on a fixed port on the local computer using the UDP (User Datagram Protocol) protocol; Design and launch multiple instance client processes, each of which listens on a random port on the local computer via UDP protocol; The client process sends a registration request packet to the server process, and after the server process successfully receives the registration request packet, the client process feeds back a signal indicating that the signal has been successfully received to the client process, and after the client process receives the feedback, the client process sends a heartbeat packet to the server process at a specific interval, and the server process waits for a response to the heartbeat packet; and The client process is to send a car bus message to the server process.

[0005] Additional features and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of the invention. The objectives and other advantages of the invention will be realized and obtained by the structure particularly pointed out in the description and drawings.

[0006] In order to make the above objects, features and advantages of the present invention more comprehensible, the following preferred embodiments will be described in detail in conjunction with the accompanying drawings. [Brief explanation of the drawings]

[0007] In order to more clearly describe the specific embodiments of the present invention or the technical solutions of the prior art, the following will briefly describe the drawings that need to be used to describe the specific embodiments or the prior art. The drawings described in the following description are some embodiments of the present invention, and it is obvious that those skilled in the art can obtain other drawings from these drawings without any creative efforts. [Figure 1] 1 is a flowchart of a method for implementing an automotive bus virtual channel according to some embodiments. [Figure 2] FIG. 1 is a principle block diagram of a system for implementing an automotive bus virtual channel according to some embodiments. [Figure 3] FIG. 1 is a principle block diagram of a system for implementing an automotive bus virtual channel according to some embodiments. [Figure 4] FIG. 1 is a principle block diagram of an electronic device according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0008] In order to clarify the objectives, technical aspects and advantages of the embodiments of the present invention, the technical aspects of the present invention will be clearly and completely described below in conjunction with the accompanying drawings. However, it is clear that the described embodiments are only some of the embodiments of the present invention and do not represent all of the embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without performing creative work fall within the scope of protection of the invention.

[0009] To simulate the communication processes of various automotive buses on a computer, virtual hardware support is provided to the bus tool, and bus tool processes from multiple manufacturers are connected via virtual hardware to enable real-time communication. Related vehicle software development techniques generally involve creating a driver program to control data transfer on the virtual bus at the system bottom layer, enabling multiple bus tool processes to be connected via virtual hardware for real-time communication. However, the method of controlling data transfer on the virtual bus by creating a driver program has the following problems: 1) After the driver program is installed, you must restart the computer before you can use it, and you cannot use it immediately after opening it. 2) The driver program and the software system are tightly bound together. If a driver program is created on a Windows system to implement a virtual channel, the driver program cannot run on a Linux system, resulting in poor portability. 3) The driver program has poor update capability. That is, even if the driver program supports virtual channels for CAN bus and LIN bus, it cannot be automatically upgraded to support new virtual channels for FlexRay bus and Ethernet.

[0010] Therefore, at least one embodiment provides a method for implementing an automotive bus virtual channel. The method includes: creating a server process as a virtual channel provider, and after starting up, listening to a fixed port on a local computer using UDP protocol; creating at least one client process, each client process instance as a virtual channel user, and after starting up, each listening to a random port on the local computer using UDP protocol; the client process sends a registration request packet to the server process, and after successfully receiving the registration request packet, the server process feeds back a signal that the client process has successfully received the signal; after receiving the feedback, the client process sends a heartbeat packet to the server process at a specific interval, and the server process waits for a response to the heartbeat packet; the client process sends an automotive bus message to the server process; if the transmission is successful, the server process sets a timestamp for the automotive bus message, returns to the client process, and modifies the direction attribute of the automotive bus message to send; and simultaneously sends the automotive bus message to the remaining client processes and modifies the direction attribute of the automotive bus message to receive.

[0011] The virtual channel provider uses the above method to realize message routing and data transmission and reception between multiple users of the virtual channel, thereby simulating the operation mechanism of message routing and data transmission and reception in a real network, realizing real-time communication, and further meeting the demand for real-time simulation.

[0012] Various non-limiting embodiments of examples of the present disclosure are described in detail below with reference to the accompanying drawings. As shown in FIG. 1, some embodiments provide a method for implementing an automobile bus virtual channel, including: In step S101, a server process is created as a provider of the virtual channel, and after being started, it listens to a fixed port of the local computer using the UDP protocol. At least one client process is created, and each client process is a user of the virtual channel, and after being started, it listens to a random port of the local computer using the UDP protocol. In step S102, the client process sends a registration request packet to the server process, and after successfully receiving the registration request packet, the server process feeds back to the client process that it has successfully received the signal, and after receiving the feedback, the client process sends a heartbeat packet to the server process at a specific interval, and the server process waits for a response to the heartbeat packet. In step S103, the client process sends an auto bus message to the server process. If the sending is successful, the server process returns to the client process after setting a timestamp for the auto bus message and modifying the direction attribute of the auto bus message to send, and simultaneously sends the auto bus message to the remaining client processes and modifies the direction attribute of the auto bus message to receive.

[0013] Specifically, a server process can provide one or more virtual channels, and each client process can use one or more virtual channels.

[0014] Taking the implementation of a virtual channel for automobile CAN network communication as an example, the implementation method for an automobile bus virtual channel provided by the embodiments of the present disclosure will be described in detail.

[0015] The following description corresponds to step S101 in some embodiments. First, an independent command-line process "VirtualCANServer.exe" is created as a server process of the CAN bus virtual channel, i.e., a virtual channel provider. After the server process is started, it starts its own UDP server and listens on a fixed port, e.g., 11898. Next, according to usage needs, multiple independent processes are created as client processes of the CAN bus virtual channel, such as a power assembly client process, a tool client process, a vehicle model client process, and an automobile chassis client process. For ease of explanation, this example focuses on the automobile chassis client process, as follows: An independent process "Chassis1.exe" is created to simulate the behavior of an ECU on the automobile chassis, and this process serves as a client process of the CAN bus virtual channel, i.e., a user of the virtual channel. After the client process is launched, it launches its own UDP server to listen on a random port, such as 50000.

[0016] The following description corresponds to step S102 in some embodiments. After the client process has been successfully launched, it sends a registration request UDP packet to the listening port 11898 of the server process. After receiving the registration request UDP packet, the server process creates a client process instance. The client process instance includes a client process UDP interception port of 50000 and a counter AliveCounter (initial value is the maximum allowable value, e.g., 10) for the client process to maintain a heartbeat. The server process then adds the client process instance to a data delivery queue grouped by channel. After the addition is complete, the server process sends a registration confirmation UDP packet to the interception port of the client process. After receiving a registration confirmation UDP packet from its own interception port 50000, the client process sets the valid flag bit of the server process, and finally sends a heartbeat packet to maintain communication to the interception port 11898 of the server process at a specific interval (for example, one UDP packet per second). After receiving the heartbeat packet of the client process, the server process resets the counter AliveCounter that maintains the heartbeat corresponding to the client process to an acceptable value, for example, 10. Then, the server process sends a UDP packet for heartbeat confirmation to the interception port 50000 of the client process, and the server process completes a response to the heartbeat packet. When the client process receives a heartbeat confirmation UDP packet from its own listening port 50000, it resets its own server feedback counter ServerCounter to an acceptable value. If the client process does not receive a heartbeat confirmation UDP packet from its own listening port 50000, it decrements the server feedback counter ServerCounter by 1. If the server feedback counter ServerCounter decreases to 0, it indicates that the client process is in error, the server process is offline, and the virtual channel has been disconnected.

[0017] The following description corresponds to step S103 in some embodiments. When a client process needs to send a CAN bus message, it sends a data transmission / reception packet containing the CAN bus message to the server process, and the data transmission / reception packet is encoded using a compression and encryption method. The data transmission / reception packet includes attributes of the CAN bus message, such as the channel index, ID, data length, and data bytes. When the server process successfully receives the CAN bus message, it first decodes it and analyzes the channel index contained in the CAN bus message to determine which virtual channel to route the CAN bus message to. Then, the server process modifies the timestamp included in the CAN bus message to the timestamp actively obtained by the server process after receiving the CAN bus message. Then, the data delivery phase begins. The server process first changes the direction of the CAN bus message to send and sends it to the client process of the automobile chassis. After the client process receives the CAN bus message from its own interception port 50000, it first decodes it to obtain the CAN bus message with the latest timestamp, so that the client process knows when the CAN bus message it sent will be responded to by other client processes. The server process then changes the direction of the CAN bus message to receive and distributes the CAN bus message to all corresponding client processes through the data distribution queue corresponding to the virtual channel. When a client process receives a CAN bus message from its own interception port 50000, it first decodes it to obtain the CAN bus message with the latest timestamp, so that the client process knows at what point in time the ECU it simulates has received the CAN bus message sent from the ECU simulated by another client process.

[0018] In some embodiments, creating the server process includes: After the server process program is started, it attempts to create a mutually exclusive amount named by the program name, and if the mutually exclusive amount exists, the creation fails and the process program is terminated. Otherwise, the creation is successful, the process program runs, and when the process program is terminated, the mutually exclusive amount is released. After the program is started, a fixed port of the local computer is intercepted, and if the interception fails, the process program is terminated to release the mutual exclusion amount.

[0019] The steps for creating a server process will be described in detail using the server process program "VirtualCANServer.exe" of the Windows-based independent CAN bus virtual channel provider as an example. After the server process program "VirtualCANServer.exe" starts, it calls the mutual exclusion API function "CreateMutex" provided by the software system to create a mutual exclusion using the name of the server process program "VirtualCANServer" as the mutual exclusion name, and then obtains the error code using the GetLastError function. If the error code is equal to the system constant "ERROR_ALREADY_EXISTS", it means that a mutual exclusion exists, the creation failed, and the server process program terminates. Otherwise, the server process program enters a normal operating state. It is explained that after the server process program enters a normal operating state, it first turns on the UDP interception port 11898. If it fails to do so, the interception port will be occupied and the server process will terminate with an error. When the server process terminates normally or abnormally, if a mutual exclusion has already been created, the API function "ReleaseMutex" is called to release the created mutual exclusion.

[0020] In some embodiments, creating at least one client process includes: After each client process program is started, it attempts to listen on any random port on the local computer, and if it fails, it attempts to listen on other random ports on the local computer until it succeeds.

[0021] Taking the user client process program "Chassis1.exe" of the CAN bus virtual channel on the Windows side as an example, the creation of at least one client process will be described in detail. After the client process program "Chassis1.exe" starts, it starts its own UDP server and listens on a random port, for example, 50000. If the listening fails, it will generate another random port, for example, 32768, and continue listening on that port until it is successful. Assuming that the port that is successfully listened is 12345, the client process program enters normal operation and continues listening on that port.

[0022] In some embodiments, the registration request packet includes a random port number that the client process listens on, and the heartbeat packet includes a random port number that the client process listens on.

[0023] In some embodiments, after the client process is successfully launched, it sends a registration request UDP packet to port 11898 of the server process, which includes the UDP listening port of the client process, for example, 50000. After the client process has successfully registered with the server process, it sends a heartbeat maintenance UDP packet to port 11898 of the server process, which contains the UDP listening port of the client process, for example, 50000.

[0024] In some embodiments, the server process sets a timestamp for the car bus message, which includes: After the server process starts, it reads the current system performance counter values and stores them in variable T1. After the server process receives the car bus message sent from the client process, it again reads and stores the current system performance counter value in variable T2. The timestamp T=(T2-T1) / F, where F is the frequency of the system performance counter.

[0025] A timestamp must be set for the server process to process bus messages. On Windows platforms, when the server process starts, it calls the QueryPerformanceFrequency system API function to obtain the frequency of the system performance counter and stores it in variable F. It also calls the QueryPerformanceCounter system API function to obtain the current system performance counter value and stores it in variable T1.

[0026] When the server process receives a message sent from a client process, it calls the QueryPerformanceCounter system API function to obtain the current system performance counter value and store it in variable T2. The timestamp of the message is T = (T2 - T1) / F. When the message sent from the client process is successfully responded to on the CAN bus, the timestamp of the message is determined, and all ECUs that receive the message will have the same timestamp.

[0027] Some embodiments further provide a system for implementing an automotive bus virtual channel, as shown in Figure 2. The system includes a computer device configured to execute a client process and a server process. As a user of the virtual channel, the client process is configured to send a registration request packet to the server process, send a heartbeat packet to the server process at a specific interval time, and send an automobile bus message to the server process. As a virtual channel provider, the server process is configured to receive registration request packets, heartbeat packets, and automobile bus messages sent from a client process, and to return to the client process after setting a timestamp for the automobile bus message and modify it to send a direction attribute of the automobile bus message, and at the same time to send this automobile bus message to another client process and modify it to receive a direction attribute of the automobile bus message.

[0028] Some embodiments further provide a system for implementing an automotive bus virtual channel, as shown in Figure 3. The system includes a computer device, the computer device having a process creation module and configured to execute a client process and a server process. The process creation module is configured to create a server process and at least one client process. As a user of the virtual channel, the client process is configured to send a registration request packet to the server process, send a heartbeat packet to the server process at a specific interval time, and send an automobile bus message to the server process. As a virtual channel provider, the server process is configured to receive registration request packets, heartbeat packets, and automobile bus messages sent from a client process, and to return to the client process after setting a timestamp for the automobile bus message and modify it to send a direction attribute of the automobile bus message, and at the same time to send this automobile bus message to another client process and modify it to receive a direction attribute of the automobile bus message. The specific implementation functions of the process creation module, client process, and server process are realized in a computer device, and specific details can be found in the content of the above-mentioned method for realizing an automobile bus virtual channel, so the description will be omitted here.

[0029] Hereinafter, an electronic device according to an embodiment of the present disclosure will be described from the viewpoint of hardware processing. The embodiments of the present disclosure are not limited to specific implementations of electronic devices. As shown in FIG. 3 , some embodiments further provide an electronic device, including at least one memory for storing commands, and at least one processor for executing the commands to cause the processor to perform the following operations: create a server process as a provider of the virtual channel, and listen on a fixed port of the local computer after startup; create at least one client process, each as a user of the virtual channel, and listen on a random port of the local computer after startup; the client process sends a registration request packet to the server process, and after successfully receiving the registration request packet, the server process feeds back a signal that the client process has successfully received the signal; after receiving the feedback, the client process sends a heartbeat packet to the server process at a specific interval, and the server process waits for a response to the heartbeat packet; the client process sends an automotive bus message to the server process; if the transmission is successful, the server process sets a timestamp for the automotive bus message, returns to the client process, and modifies the direction attribute of the automotive bus message to send; and simultaneously sends the automotive bus message to another client process and modifies the direction attribute of the automotive bus message to receive.

[0030] In some embodiments, creating a server process (step) includes: after the server process program is started, attempting to create a mutually exclusive quantity named by the program name, and if the mutually exclusive quantity exists, the creation fails and the process program is terminated; otherwise, the creation is successful, the process program runs, and when the process program is terminated, the mutually exclusive quantity is released; after the program is started, listening on a fixed port of the local computer, and if the listening fails, the process program is terminated and the mutually exclusive quantity is released.

[0031] In some embodiments, creating at least one client process includes: after the at least one client process program is launched, attempting to listen on any random port on the local computer, and if the interception fails, attempting to listen on other random ports on the local computer until the interception is successful;

[0032] In some embodiments, the registration request packet includes a random port number that the client process listens on, and the heartbeat packet includes a random port number that the client process listens on.

[0033] In some embodiments, the server process sets a timestamp for the car bus message, including: After the server process starts, it reads the current system performance counter value and stores it in a variable T1; After the server process receives the car bus message sent from the client process, it reads the current system performance counter value again and stores it in a variable T2; The timestamp T=(T2-T1) / F, where F is the frequency of the system performance counter.

[0034] In other embodiments, computer equipment, industrial computers, etc. may also be types of electronic devices.

[0035] The configuration shown in FIG. 3 is not intended to limit the electronic device, which may include fewer or more components than shown, some components may be combined, or different component arrangements may be used.

[0036] In some embodiments, the communication interface may be a communication interface connectable to an external bus adapter, such as RS232, RS485, a USB port, a TYPE port, etc. A wired or wireless network interface may also be included, and the network interface may optionally include a wired and / or wireless interface (e.g., a WI-FI interface, a Bluetooth interface, etc.) typically used to establish a communication connection between the computing device and other electronic devices. The readable storage medium or computer-readable storage medium includes at least one type of memory. Memory includes flash memory, hard disk, multimedia card, card-type memory (e.g., SD memory), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, it may be an internal storage unit of a computer device, such as a hard disk of the computer device. In other embodiments, the memory may be an external storage device of a computer device, such as a plug-in hard disk installed in the computer device, a SmartMedia Card (SMC)®, a Secure Digital Card (SD), a Flash Card, etc. Furthermore, the memory may include both an internal storage unit of a computer device and an external storage device. The memory is used to store various data, such as application software and computer program code installed in the computer device, as well as to temporarily store output data or data to be output.

[0037] In some embodiments, the processor may be a Central Processing Unit (CPU), controller, microcontroller, microprocessor, or other data processing chip that executes program code stored in memory or processes data, for example, to execute a computer program.

[0038] In some embodiments, the communication bus may be an input / output bus, which may be a Peripheral Component Interconnect (PCI) bus or an Enhanced Industry Standard Architecture (EISA) bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc.

[0039] Optionally, the computer device may further include a user interface. The user interface may include input units such as a display and a keyboard, and optionally, the user interface may also include a standard wired interface or a wireless interface. Optionally, in some embodiments, the display may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, an OLED (Organic Light-Emitting Diode) touch device, etc. In this case, the display is also called a display screen or a display unit, since it displays information processed in the computer device and a visualized user interface.

[0040] When the processor executes the program, it implements the steps in the embodiment of the method for realizing an automotive bus virtual channel shown in Figure 1, for example, steps S101 to S103 shown in Figure 1. Alternatively, when the processor executes the computer program, it implements the functions of each module or unit in each of the embodiments of the device.

[0041] In some embodiments, the processor is specifically adapted to implement the following steps: A server process is created as a virtual channel provider, and after it is started, it listens on a fixed port on the local computer using the UDP protocol. At least one client process is created, and each client process acts as a user of the virtual channel, and after being started, each client process listens to a random port of the local computer by the UDP protocol. The client process sends a registration request packet to the server process, and after successfully receiving the registration request packet, the server process feeds back to the client process that it has successfully received the signal, and after receiving the feedback, the client process sends a heartbeat packet to the server process at a specific interval, and the server process waits for a response to the heartbeat packet. The client process sends a car bus message to the server process, and if the sending is successful, the server process returns to the client process after setting a timestamp for the car bus message and modifies the direction attribute of the car bus message to send, and simultaneously sends the car bus message to another client process and modifies the direction attribute of the car bus message to receive.

[0042] Optionally, in a possible embodiment, the processor is further used to implement the following steps: Creating a server process (steps) includes: After the server process program is started, it attempts to create a mutually exclusive amount named by the program name, and if the mutually exclusive amount exists, the creation fails and the process program is terminated. Otherwise, the creation is successful, the process program runs, and when the process program is terminated, the mutually exclusive amount is released. After the program is started, a fixed port of the local computer is intercepted, and if the interception fails, the process program is terminated to release the mutual exclusion amount.

[0043] Optionally, in a possible embodiment, the processor is further used to implement the following steps: Creating at least one client process includes: After each client process program is started, it attempts to listen on any random port on the local computer, and if it fails, it attempts to listen on other random ports on the local computer until it succeeds.

[0044] Optionally, in a possible embodiment, the processor is further used to implement the following steps: The registration request packet includes a random port number that the client process listens on, and the heartbeat packet includes a random port number that the client process listens on.

[0045] Optionally, in a possible embodiment, the processor is further used to implement the following steps: The server process setting the timestamp of the car bus message includes: After the server process starts, it reads the current system performance counter values and stores them in variable T1. After the server process receives the car bus message sent from the client process, it again reads and stores the current system performance counter value in variable T2. The timestamp T=(T2-T1) / F, where F is the frequency of the system performance counter.

[0046] Some embodiments further provide a computer-readable storage medium, which stores a program for implementing a vehicle bus virtual channel. When the program is executed by a processor, specific steps of the vehicle bus virtual channel implementation method can be implemented. However, the specific description of the vehicle bus virtual channel implementation method is omitted and reference is made to the detailed description of the vehicle bus virtual channel implementation method.

[0047] Some embodiments further provide a computer program product, comprising computer programs or commands that, when executed on a computer, cause the computer to perform any of the above possible methods for implementing an automotive bus virtual channel.

[0048] In the vehicle development and debugging system of some embodiments, the specific method for realizing the vehicle bus virtual channel is the same as the above-mentioned method for realizing the vehicle bus virtual channel, and therefore the description is omitted here.

[0049] In some embodiments of the present invention, it should be understood that the disclosed apparatus and method may be implemented in other ways. The apparatus embodiments described above are merely examples. For example, the flowcharts and block diagrams in the drawings illustrate possible architectures, functions, and operations of apparatuses, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, a program segment, or a portion of code. The module, program segment, or portion of code includes executable instructions for implementing one or more predetermined logical functions. Note that in some alternative implementations, the functions depicted in the blocks may occur in a different order than depicted in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, or may sometimes be executed in the reverse order, depending on the functionality involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented in a dedicated hardware-based system that performs the predetermined functions or operations, or in a combination of dedicated hardware and computer instructions.

[0050] Furthermore, each functional module in each embodiment of the present invention may be integrated together to form a single independent part, each module may exist independently, or two or more modules may be integrated to form a single independent part.

[0051] The above functions can be realized in the form of software functional modules and stored in a computer-readable storage medium when sold or used as an independent product. Based on this understanding, the technical solution of the present invention essentially or a part that contributes to the prior art or a part of the technical solution can be expressed in the form of a software product. The computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, a server, a network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present invention.

[0052] The above-described preferred embodiments of the present invention have been enlightened, and those skilled in the art can make various changes and modifications based on the above description without departing from the technical spirit of the present invention. The technical scope of the present invention is not limited to the content of the specification, but should be determined based on the claims.

Claims

1. 1. A method for implementing an automotive bus virtual channel, comprising: The client process sends a registration request packet to the server process, and the server process, after successfully receiving the registration request packet, feeds back to the client process that the signal has been successfully received; the client process, after receiving the feedback, sends a heartbeat packet to the server process at a specific interval, and the server process waits for a response to the heartbeat packet; A computer-implemented method for implementing an automotive bus virtual channel, wherein a client process sends an automotive bus message to a server process.

2. A computer-implemented method for implementing an automotive bus virtual channel as described in claim 1, characterized in that the client process sends an automotive bus message to a server process, and if the transmission is successful, the server process returns to the client process after setting a timestamp of the automotive bus message and modifies the direction attribute of the automotive bus message to send, and at the same time sends this automotive bus message to another client process and modifies the direction attribute of the automotive bus message to receive.

3. The server process sets the timestamp of the car bus message, After the server process has started, reading and storing the current system performance counter value in a variable T1; the server process, after receiving the car bus message sent from the client process, again reads and stores the current system performance counter value in variable T2; 2. The computer implemented method for implementing an automotive bus virtual channel of claim 1, wherein the timestamp T=(T2-T1) / F, where F is the frequency of a system performance counter.

4. A computer-readable storage medium, comprising:

10. A computer-readable storage medium storing computer-readable instructions that, when executed by at least one processor, cause the processor to execute the program for the method of implementing an automotive bus virtual channel as recited in claim 1.

5. An electronic device, at least one memory that stores commands; and at least one processor that executes the commands to cause the processor to perform the following operations: configured to run a client process and a server process; The client process sends a registration request packet to the server process, and after the server process has successfully received the registration request packet, it sends a signal to the client process as feedback that it has successfully received the signal. After the client process has received the feedback, it sends a heartbeat packet to the server process at a specific interval, and the server process waits for a response to the heartbeat packet. An electronic device, characterized in that a client process sends an automobile bus message to a server process.

6. The electronic device described in claim 5, wherein the client process sends an automotive bus message to the server process, and if the sending is successful, the server process returns to the client process after setting a timestamp of the automotive bus message and modifies the direction attribute of the automotive bus message to send, and at the same time sends this automotive bus message to another client process and modifies the direction attribute of the automotive bus message to receive.

7. The server process sets the timestamp of the car bus message, After the server process has started, reading and storing the current system performance counter value in a variable T1; the server process, after receiving the car bus message sent from the client process, again reads and stores the current system performance counter value in variable T2; 6. The electronic device of claim 5, wherein the timestamp T=(T2-T1) / F, where F is the frequency of the system performance counter.

8. 1. A system for implementing an automotive bus virtual channel, comprising: a computer device configured to execute a client process and a server process; The client process sends a registration request packet to the server process, sends a heartbeat packet to the server process at a specific interval, and sends an automobile bus message to the server process; A system for realizing an automotive bus virtual channel, characterized in that a server process receives a registration request packet, a heartbeat packet, and an automotive bus message sent from a client process, and after successfully receiving the registration request packet, feeds back to the client process that the signal was successfully received.

9. The system for realizing an automotive bus virtual channel as described in claim 8, wherein the server process further sets a timestamp for the automotive bus message before returning to the client process and modifying the direction attribute of the automotive bus message to send, and at the same time sending this automotive bus message to another client process and modifying it to receive the direction attribute of the automotive bus message.

10. The server process sets the timestamp of the car bus message, After the server process has started, reading and storing the current system performance counter value in a variable T1; the server process, after receiving the car bus message sent from the client process, again reads and stores the current system performance counter value in variable T2; 9. The system for realizing an automobile bus virtual channel according to claim 8, wherein the timestamp T=(T2-T1) / F, where F is the frequency of the system performance counter.

11. A program for causing a computer to execute the method for realizing an automobile bus virtual channel according to any one of claims 1 to 3.

Images