Method and System for Implementing a Virtual Channel for a Motor Bus

Abstract

To specifically provide an achievement method of an automobile bus virtual channel belonging to a vehicle software development technology field.SOLUTION: An achievement method of an automobile bus virtual channel includes: designing a single instance server process; monitoring a fixed port of a local computer after having started the process, with UDP protocols; and designing a plurality of instance client processes; and monitoring random ports of the local computer with respective UDP protocols after having started the processes. A client process transmits a registration request packet to a server process. After having successfully received the registration request packet, the server process feeds back to the client process that the signal has been successfully received. After having received the feedback, the client process transmits heartbeat packets to the server process at prescribed interval time periods. The method further includes the server process waiting for the response to the heartbeat packet and the client process transmitting an automobile bus message to the server process.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] This application claims the Chinese Patent Application No. 2023114028853 filed on October 26, 2023, and the US Patent Application No. 18 / 380,187 filed on October 15, 2023, based on priority, and all of its contents are incorporated herein by reference.

[0002] The present invention belongs to the technical field of vehicle software development, and specifically relates to a method and system for realizing an automotive bus virtual channel.

Background Art

[0003] In order to realize the communication process of simulating various automotive buses on a computer, virtual hardware support is provided for bus tools, and multiple bus tool processes are connected by virtual hardware and can perform real-time communication. In the conventional vehicle software development technology, it is common to control the data transfer of the virtual bus at the lower layer of the system by creating a driver.

Summary of the Invention

[0004] The present invention relates to a method for realizing an automotive bus virtual channel. This method includes the following. Design a single-instance server process, and after startup, listen to the fixed port of the local computer by the UDP (User Datagram Protocol) protocol. Design multiple instance client processes, and after startup, each listen to the random port of the local computer by the UDP protocol. The client process sends a registration request packet to the server process. After successfully receiving the registration request packet, the server process feeds back to the client process that it has successfully received the signal. After receiving the feedback, the client process sends a heartbeat packet to the server process at specific intervals, and the server process waits for a response to the heartbeat packet, and the client process sends an automotive bus message to the server process.

[0005] Other features and advantages of the present invention are described in the following specification, and some are obvious from the specification or can be understood by implementing the present invention. The objectives and other advantages of the present invention are realized and obtained by the structure specifically pointed out in the specification and drawings.

[0006] To make the above objectives, features, and advantages of the present invention clearer, the following provides preferred embodiments and, in conjunction with the accompanying drawings, will be described in detail.

Brief Description of the Drawings

[0007] To more clearly explain the specific embodiments of the present invention or the technical solutions of the prior art, the following briefly describes the drawings that need to be used in the description of 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 creative effort.

Figure 1

Figure 2

Figure 3

Figure 4

Best Mode for Carrying Out the Invention

[0008] To make the objectives, technical aspects, and advantages of the embodiments of the present invention clearer, the technical aspects of the present invention will be clearly and completely described below in connection with the accompanying drawings. However, it is obvious that the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained on the premise that those skilled in the art do not perform creative labor belong to the scope of protection of the invention.

[0009] To realize simulating the communication processes of various automotive buses on a computer, virtual hardware support is provided for the bus tool, and the processes of bus tools from multiple different manufacturers are connected by virtual hardware, enabling real-time communication. In related vehicle software development technologies, generally, a driver program is created to control the data transmission of the virtual bus at the system bottom layer, enabling connection between multiple bus tool processes via virtual hardware and performing real-time communication. However, there are the following problems with the method of controlling the data transfer of the virtual bus by creating a driver program. 1) After the driver program is installed, the computer must be restarted before it can be used, and it cannot be used immediately after it is opened. 2) The driver program and the software system are tightly bound. When a driver program is created on the Windows system to realize a virtual channel, the driver program cannot operate on the Linux (registered trademark) system, and its portability is poor. 3) The update ability of the driver program is poor. That is, even if the driver program supports the virtual channels of the CAN bus and the LIN bus, it cannot automatically upgrade to support the new virtual channels of the FlexRay bus and Ethernet.

[0010] Therefore, at least one embodiment provides a method for implementing an automotive bus virtual channel. This method includes the following steps. Create a server process to act as a provider of the virtual channel, and after startup, intercept the fixed port of the local computer using the UDP protocol. Create at least one client process, with each client process instance acting as a virtual channel user, and after startup, intercept the random port of the local computer using the UDP protocol respectively. The client process sends a registration request packet to the server process, and after successfully receiving the registration request packet, the server process feedbacks to the client process that it has successfully received the signal. After receiving the feedback, the client process sends a heartbeat packet to the server process at specific intervals, and the server process waits for a response to the heartbeat packet. The client process sends an automotive bus message to the server process. Upon successful transmission, the server process sets the timestamp of the automotive bus message and then returns to the client process, modifies the direction attribute of the automotive bus message to reception, and simultaneously sends this automotive bus message to the remaining client processes and modifies the direction attribute of the automotive bus message to reception.

[0011] The provider of the virtual channel realizes message routing and data transmission and reception among multiple users of the virtual channel by the above method, thereby simulating the operating mechanism in the actual network of message routing and data transmission and reception, realizing real-time communication, and further realizing the need for real-time simulation.

[0012] Hereinafter, various non-limiting embodiments of the embodiments of the present disclosure will be described in detail in connection with the accompanying drawings. As shown in FIG. 1, some embodiments provide a method for implementing an automotive bus virtual channel, including the following. In step S101, a server process is created to serve as a provider of virtual channels. After startup, it intercepts the fixed port of the local computer via the UDP protocol. At least one client process is created, and each client process serves as a user of a virtual channel. After startup, each intercepts a random port of the local computer via the UDP protocol. In step S102, the client process sends a registration request packet to the server process. After successfully receiving the registration request packet, the server process feedbacks to the client process that it has successfully received the signal. After receiving the feedback, the client process sends a heartbeat packet to the server process at specific intervals, and the server process waits for a response to the heartbeat packet. In step S103, the client process sends an automotive bus message to the server process. Upon successful transmission, the server process sets the timestamp of the automotive bus message and then returns to the client process, and modifies the direction attribute of the automotive bus message to reception while sending this automotive bus message to the remaining client processes and modifying the direction attribute of the automotive bus message to reception.

[0013] Specifically, the server process can provide one or more virtual channels. Each client process can use one or more virtual channels.

[0014] Taking the realization of a virtual channel for automotive CAN network communication as an example, the method for realizing an automotive 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, create an independent command line process "VirtualCANServer.exe" as the server process for the CAN bus virtual channel, that is, the provider of the virtual channel. After the server process is started, start its own UDP server and listen on a fixed port, for example, 11898. Next, according to the usage needs, create a plurality of independent processes as the client processes of the CAN bus virtual channel respectively, such as the power assembly client process, the tool client process, the vehicle model client process, the automobile chassis client process, etc. For the sake of easy explanation, this example emphasizes and explains the client process of the automobile chassis, specifically as follows. Create an independent process "Chassis1.exe" to simulate the behavior of the ECU on the automobile chassis. This process is used as the client process of the CAN bus virtual channel, that is, the user of the virtual channel. After the client process is started, start its own UDP server and listen on a random port, for example, 50000.

[0016] The following description corresponds to step S102 in several embodiments. After the client process is successfully started, send a UDP packet for registration request to the listening port 11898 of the server process. After the server process receives the UDP packet for registration request, create one client process instance. The client process instance includes the UDP listening port 50000 of the client process and a counter AliveCounter (the initial value is the maximum allowable value, for example, 10) that the client process uses to maintain the heartbeat. Further, add the client process instance to the data distribution queue grouped by channel. After the addition is completed, the server process sends a UDP packet for registration confirmation to the listening port of the client process. After receiving the UDP packet for registration confirmation from its own listening port 50000, the client process sets the valid flag bit of the server process, and finally sends a heartbeat packet for maintaining communication to the listening port 11898 of the server process at a specific interval (for example, the transmission frequency of one UDP packet per second). After receiving the heartbeat packet of the client process, the server process resets the counter AliveCounter for maintaining the heartbeat corresponding to the client process to an allowable value, for example, 10. Subsequently, the server process sends a UDP packet for heartbeat confirmation to the listening port 50000 of the client process, and the server process completes the response to the heartbeat packet. When the client process receives the UDP packet for heartbeat confirmation from its own listening port 50000, it resets its server feedback counter ServerCounter to the allowable value. If the client process does not receive the UDP packet for heartbeat confirmation from its own listening port 50000, it decrements the server feedback counter ServerCounter by 1. When the server feedback counter ServerCounter decreases to 0, it indicates that the client process has an 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 the 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 realizes encoding through a compression and encryption method. The data transmission / reception packet includes attributes such as the channel index, ID, data length, and data bytes of the CAN bus message. When the server process successfully receives the CAN bus message, it first decrypts it, analyzes the channel index of the CAN bus message, and determines which virtual channel to route the CAN bus message to. Subsequently, 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. Subsequently, it enters the data distribution stage. The server process first changes the direction of the CAN bus message to transmission and sends it to the client process of the vehicle chassis. After the client process receives the CAN bus message from its own listening port 50000, it first decrypts it to obtain the CAN bus message with the latest timestamp, and the client process knows at what time 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 reception and distributes the CAN bus message to all corresponding client processes through the data distribution queue corresponding to the virtual channel. When the client process receives the CAN bus message from its own listening port 50000, it first decrypts it to obtain the CAN bus message with the latest timestamp, and the client process knows at what point in time the ECU it simulated received the CAN bus message sent from the ECU simulated by other client processes.

[0018] In some embodiments, creating the server process (step) includes the following. After the above server process program is started, an attempt is made to create a mutex named after the program name. If the mutex exists, the creation fails and the process program is terminated. Otherwise, the creation is successful, the process program operates, and when the process program terminates, the mutex is released. After the program is started, the fixed port of the local computer is intercepted. If the interception fails, the process program is terminated and the mutex is released.

[0019] Taking the server process program "VirtualCANServer.exe" of the provider of the independent CAN bus virtual channel on the Windows side as an example, the steps to create the server process will be described in detail. After the server process program "VirtualCANServer.exe" is started, the mutex API function "CreateMutex" provided by the software system is called to create a mutex with the name of the server process program "VirtualCANServer" as the mutex name, and then the error code is obtained by the GetLastError function. If the error code is equal to the system constant "ERROR_ALREADY_EXISTS", it means that the mutex exists, the creation fails, and the server process program is terminated. Otherwise, the server process program enters the normal operating state. After the server process program enters the normal operating state, first turn on the UDP interception port 11898. If the turn-on fails, it means that the interception port is occupied and the server process ends with an error. When the server process terminates, whether it is normal or abnormal, if the mutex has already been created, the API function "ReleaseMutex" is called to release the created mutex.

[0020] In some embodiments, creating at least one client process (step) includes the following. After each client process program is started, it attempts to intercept any random port on the local computer. If the interception fails, it attempts to intercept other random ports on the local computer until the interception is successful.

[0021] Taking the client process program "Chassis1.exe" of the user of the Windows-side CAN bus virtual channel as an example, at least one client process will be created in detail. After the client process program "Chassis1.exe" is started, it starts its own UDP server and intercepts a random port, for example, 50000. If the interception fails, it generates another random port, for example, 32768, and continues to attempt to intercept this port until the interception is successful. Assuming that the port successfully intercepted is 12345, the client process program enters the normal operating state and continues to intercept this port.

[0022] In some embodiments, the registration request packet includes the random port number intercepted by the client process. Also, the heartbeat packet includes the random port number intercepted by the client process.

[0023] In some embodiments, after the client process is successfully started, a UDP packet for registration request is sent to port 11898 of the server process. The UDP packet for registration request has the UDP interception port of this client process, for example, 50000. After the client process successfully registers with the server process, a UDP packet for maintaining heartbeat is sent to port 11898 of the server process. The UDP packet for maintaining heartbeat has the UDP interception port of this client process, for example, 50000.

[0024] In some embodiments, the server process sets the timestamp of the vehicle bus message and includes the following. After the server process starts, read the current system performance counter value and store it in variable T1. After the server process receives the automotive bus message sent from the client process, read the current system performance counter value again and store it in variable T2. The time stamp T = (T2 - T1) / F, where F is the frequency of the system performance counter.

[0025] The server process needs to set a time stamp to process the bus message. On the Windows platform, when the server process starts, call the QueryPerformanceFrequency system API function to obtain the frequency of the system performance counter and store it in variable F. Further, call the QueryPerformanceCounter system API function to obtain the current system performance counter value and store it in variable T1.

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

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

[0028] As shown in Figure 3, some embodiments further provide a realization system of an automotive bus virtual channel. This system includes a computer device, and the computer device has a process creation module and is 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. The client process, as a user of the virtual channel, is configured to send a registration request packet to the server process, send a heartbeat packet to the server process based on a specific interval time, and also send an automotive bus message to the server process. The server process, as a provider of the virtual channel, is configured to receive the registration request packet, heartbeat packet, and automotive bus message sent from the client process, return to the client process after setting the timestamp of the automotive bus message, and modify to send the direction attribute of the automotive bus message, and at the same time send this automotive bus message to other client processes and modify to receive the direction attribute of the automotive bus message. The specific implementation functions of the process creation module, client process, and server process are realized in a computer device. Specifically, reference can be made to the content of the above method for realizing an automotive bus virtual channel, so the description is omitted here.

[0029] Hereinafter, the electronic device according to the embodiments of the present disclosure will be described from the perspective of hardware processing. The embodiments of the present disclosure do not limit the specific implementation of the electronic device. 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 above commands to cause the processor to execute the following operations. Create a server process as a virtual channel provider, and after starting, intercept the fixed port of the local computer. Create at least one client process, each client process being a user of the virtual channel respectively, and after starting, intercept the random port of the local computer respectively. The client process sends a registration request packet to the server process, and after successfully receiving the registration request packet, the server process feedbacks to the client process that it has successfully received the signal. After receiving the feedback, the client process sends a heartbeat packet to the server process at a specific interval time, and the server process waits for a response to the heartbeat packet. The client process sends an automotive bus message to the server process. When the transmission is successful, the server process sets the timestamp of the automotive bus message and then returns to the client process, and modifies the direction attribute of the automotive bus message to reception while sending this automotive bus message to other client processes and modifying the direction attribute of the automotive bus message to reception.

[0030] In some embodiments, creating the server process (step) includes the following. After the server process program is started, an attempt is made to create a mutually exclusive quantity named after the program name. If the mutually exclusive quantity exists, the creation fails and the process program ends. Otherwise, the creation is successful, the process program operates, and the mutually exclusive quantity is released when the process program ends. After the program is started, the fixed port of the local computer is intercepted. If the interception fails, the process program ends and the mutually exclusive quantity is released.

[0031] In some embodiments, creating at least one client process (step) includes the following. After the at least one client process program is started, an attempt is made to intercept any random port of the local computer. If the interception fails, an attempt is made to intercept other random ports of the local computer until the interception is successful.

[0032] In some embodiments, the registration request packet includes the random port number intercepted by the client process. Also, the heartbeat packet includes the random port number intercepted by the client process.

[0033] In some embodiments, the server process sets the timestamp of the automotive bus message and includes the following. After the server process is started, the current system performance counter value is read and stored in variable T1. After the server process receives the automotive bus message sent from the client process, the current system performance counter value is read again and stored in variable T2. The timestamp T = (T2 - T1) / F, where F is the frequency of the system performance counter.

[0034] In other embodiments, a computer device, an industrial computer can also be regarded as a kind of electronic device.

[0035] The configuration shown in FIG. 3 does not limit the electronic device, and it may include fewer or more components than shown in the figure, some components may be combined, or different components may be arranged.

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

[0037] In some embodiments, the processor may execute program code stored in the memory or process data, such as a Central Processing Unit (CPU) for executing a computer program, a controller, a microcontroller, a microprocessor, or other data processing chips.

[0038] In some embodiments, the communication bus may be an input / output bus such as a Peripheral Component Interconnect (PCI) bus or an Enhanced Industry Standard Architecture (EISA) bus. This bus can be divided into an address bus, a data bus, a control bus, and the like.

[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. Optionally, the user interface may also include a standard wired interface and a wireless interface. Optionally, in some embodiments, the display may be an LED display, a liquid crystal display, a touch liquid crystal display, an OLED (Organic Light-Emitting Diode) touch device, or the like. In this case, the display is also called a display screen or a display unit for displaying the information processed in the computer device and for displaying the visualized user interface.

[0040] When the above processor executes the above program, it realizes the steps in the embodiment of the method for realizing the virtual channel of the automotive bus shown in FIG. 1 above, such as steps S101 to S103 shown in FIG. 1. Alternatively, when the processor executes a computer program, it realizes the functions of each module or unit in the embodiments of the above respective devices.

[0041] In some embodiments, the processor is specifically used to implement the following steps. Create a server process to serve as a provider of virtual channels, and after startup, intercept the fixed port of the local computer through the UDP protocol. Create at least one client process, each client process serving as a user of a virtual channel, and after startup, intercept the random port of the local computer through the UDP protocol respectively. The client process sends a registration request packet to the server process. After successfully receiving the registration request packet, the server process feedbacks to the client process that it 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. Upon successful transmission, the server process sets the timestamp of the automotive bus message, then returns to the client process, modifies the direction attribute of the automotive bus message for reception, and simultaneously sends this automotive bus message to other client processes and modifies the direction attribute of the automotive bus message for reception.

[0042] Optionally, as a possible embodiment, the processor is further used to implement the following steps. Creating the server process (step) includes the following. After the above server process program starts, attempt to create a mutex named with the program name. If the mutex exists, the creation fails and the process program ends. Otherwise, the creation is successful, the process program operates, and the mutex is released when the process program ends. After the program starts, monitor the fixed port of the local computer. If the monitoring fails, terminate the process program and release the mutex.

[0043] Optionally, as a possible embodiment, the processor is further used to implement the following steps. Creating at least one client process (step) includes the following. After each client process program starts, attempt to monitor any random port of the local computer. If the monitoring fails, attempt to monitor other random ports of the local computer until the monitoring is successful.

[0044] Optionally, as a possible embodiment, the processor is further used to implement the following steps. The registration request packet includes the random port number monitored by the client process. Also, the heartbeat packet includes the random port number monitored by the client process.

[0045] Optionally, as a possible embodiment, the processor is further used to implement the following steps. The server process setting the timestamp of the vehicle bus message includes the following. After the server process starts, read the current system performance counter value and store it in variable T1. After the server process receives the vehicle bus message sent from the client process, read the current system performance counter value again and store it 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, on which a program for a method of implementing an automotive bus virtual channel is stored. When the program is executed by a processor, specific steps of the method of implementing an automotive bus virtual channel can be realized. For specific descriptions of the method of implementing an automotive bus virtual channel, reference may be made thereto, and the descriptions are omitted herein.

[0047] Some embodiments further provide a computer program product, which includes a computer program or command. When the computer program or command is executed on a computer, the computer is caused to execute any of the possible methods of implementing an automotive bus virtual channel described above.

[0048] In the vehicle development debugging system of some embodiments, the specific method related to the method of implementing an automotive bus virtual channel is the same as the method of implementing an automotive bus virtual channel described above, and the descriptions are omitted herein.

[0049] In some embodiments provided by the present invention, naturally, the disclosed apparatus and method can also be implemented in other ways. The embodiments of the apparatus described above are merely illustrative. For example, the flowcharts and block diagrams in the drawings show the possible architectures, functions, and operations of the apparatus, method, and computer program product according to multiple embodiments of the present invention. In this regard, each block in the flowchart or block diagram can represent a module, a program segment, or a part of the code. The above module, program segment, or part of the code includes executable instructions for implementing one or more predetermined logical functions. It should be noted that in some alternative implementation ways, the functions represented by the blocks may occur in an order different from the order shown in the drawings. For example, two consecutive blocks can actually be executed substantially in parallel and, depending on the related functions, can sometimes be executed in the reverse order. Also, each block in the block diagram and / or flowchart, as well as the combination of the blocks in the block diagram and / or flowchart, may be implemented by a dedicated hardware-based system for performing a predetermined function or operation, or may be implemented by a combination of dedicated hardware and computer instructions.

[0050] Moreover, each functional module in each embodiment of the present invention may be integrated together to form an independent part, each module may exist alone, or two or more modules may be integrated to form an independent part.

[0051] If the above functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present invention, in essence or the part that contributes to the prior art or a part of the technical solution, can be represented in the form of a software product. The computer software product is stored in a storage medium and includes a plurality of instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in each embodiment of the present invention.

[0052] Inspired by the preferred embodiments of the present invention described above, those skilled in the art can make various changes and modifications without departing from the technical idea of the present invention from the above description. The technical scope of the present invention is not limited to the content of the specification, and its technical scope must be determined based on the scope of the claims.

Claims

1. 1. A method for implementing an automotive bus virtual channel, comprising: creating and starting a server process as a virtual channel provider and, after starting the process, listening on a fixed port on the local computer; Creating at least one client process, each client process being a user of a virtual channel, and each client process being started and then sniffing a random port of a local computer; The client process sends a registration request packet to the server process, and the server process feeds back to the client process that the signal has been successfully received after successfully receiving the registration request packet, and the client process sends a heartbeat packet to the server process at a specific interval after receiving the feedback, and the server process waits for a response to the heartbeat packet; A computer-implemented method for implementing an automotive bus virtual channel, comprising: a client process sending an automotive bus message to a server process; if the sending is successful, the server process returning to the client process after setting a timestamp of the automotive bus message, and modifying a direction attribute of the automotive bus message to send; and at the same time sending the automotive bus message to another client process, and modifying the direction attribute of the automotive bus message to receive.

2. 1. A method for implementing an automotive bus virtual channel, comprising: Creating a server process After the server process program is started, attempt 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 succeeds, the process program runs, and when the process program is terminated, the mutually exclusive amount is released; 2. The computer-implemented method for implementing an automobile bus virtual channel according to claim 1, further comprising: intercepting a fixed port of the local computer after the program is started; and, if the interception fails, terminating the process program to release the mutual exclusion amount.

3. 1. A method for implementing an automotive bus virtual channel, comprising: Creating at least one client process 2. The computer-implemented method for implementing an automobile bus virtual channel as described in claim 1, further comprising the steps of: after each client process program is started, attempting to intercept any random port of the local computer; and if the interception fails, attempting to intercept other random ports of the local computer until the interception is successful.

4. The registration request packet includes a random port number that is listened for by the client process; 4. The computer implemented method of claim 3, wherein the heartbeat packets include a random port number that a client process listens on.

5. 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 values ​​in a variable T1; The server process includes: after receiving the car bus message sent from the client process, reading again the current system performance counter value and storing it in the variable T2; 2. The computer implemented method of claim 1, wherein the time stamp T=(T2-T1) / F, where F is the frequency of the system performance counter.

6. After the server process is started, listening to a fixed port of a local computer by a UDP protocol or a TCP protocol; 2. The computer implemented method for implementing an automobile bus virtual channel as claimed in claim 1, further comprising the steps of: after each client process is started, listening to a random port of the local computer by a UDP protocol or a TCP protocol, respectively.

7. 1. A computer-readable storage medium, comprising:

13. A computer readable storage medium having stored thereon computer readable instructions which, 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.

8. An electronic device, 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 virtual channel provider, start it, and listen on a fixed port on the local computer. Create at least one client process, each client process being a user of a virtual channel, and each client process being started and listening on a random port of a local computer; The client process sends a registration request packet to the server process, and after the server process successfully receives the registration request packet, the server process feeds back to the client process that the signal has been successfully received, 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; An electronic device characterized in that a client process sends an automobile bus message to a server process, and when the sending is successful, the server process returns to the client process after setting a timestamp of the automobile bus message, and modifies a direction attribute of the automobile bus message to sending, and at the same time sends the automobile bus message to another client process, and modifies the direction attribute of the automobile bus message to receiving.

9. Creating a server process After the server process program is started, attempt 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 succeeds, the process program runs, and when the process program is terminated, the mutually exclusive amount is released; The electronic device according to claim 8, further comprising: intercepting a fixed port of the local computer after the program is started; and, if the interception fails, terminating the process program to release the mutually exclusive amount.

10. Creating at least one client process 9. The electronic device according to claim 8, further comprising: after the at least one client process program is started, attempting to intercept any random port of the local computer, and if the interception fails, attempting to intercept other random ports of the local computer until the interception is successful.

11. The registration request packet includes a random port number that is listened for by the client process; 11. The electronic device of claim 10, wherein the heartbeat packet includes a random port number that is listened on by a client process.

12. 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 values ​​in a variable T1; The server process includes: after receiving the car bus message sent from the client process, reading again the current system performance counter value and storing it in the variable T2; 9. The electronic device of claim 8, wherein the time stamp T=(T2-T1) / F, where F is the frequency of the system performance counter.

13. 1. A system for implementing an automotive bus virtual channel, comprising: a computing device configured to execute a client process and a server process; a client process configured to send a registration request packet to the server process, to send a heartbeat packet to the server process based on a specific interval time, and to send an automobile bus message to the server process; A system for realizing an automobile bus virtual channel, comprising: a server process configured to receive a registration request packet, a heartbeat packet, and an automobile bus message sent from a client process, and to return to the client process after setting a timestamp of the automobile bus message, and to modify the automobile bus message to send a directional attribute, and at the same time to send the automobile bus message to another client process, and to modify the automobile bus message to receive a directional attribute.

14. The computing device is further configured to create a server process; After the server process program is started, attempt 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 succeeds, the process program runs, and when the process program is terminated, the mutually exclusive amount is released; The system for realizing an automobile bus virtual channel as described in claim 13, further comprising: intercepting a fixed port of the local computer after the program is started, and if the interception fails, terminating the process program to release the mutual exclusion amount.

15. The computing device is further configured to create at least one client process; 14. The system for realizing an automobile bus virtual channel as described in claim 13, characterized in that after each client process program is started, it attempts to intercept any random port of the local computer, and if interception fails, it attempts to intercept other random ports of the local computer until interception is successful.

16. The registration request packet includes a random port number that is listened for by the client process; 16. The system for implementing an automobile bus virtual channel according to claim 15, wherein the heartbeat packet includes a random port number that is listened on by a client process.

17. 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 values ​​in a variable T1; The server process includes: after receiving the car bus message sent from the client process, reading again the current system performance counter value and storing it in the variable T2; 14. The system for implementing an automobile bus virtual channel as claimed in claim 13, wherein the time stamp T=(T2-T1) / F, where F is the frequency of the system performance counter.

18. After the server process is started, it listens on a fixed port of the local computer by using the UDP or TCP protocol; 14. The system for realizing an automobile bus virtual channel as claimed in claim 13, characterized in that after each client process is started, it listens on a random port of the local computer by a UDP protocol or a TCP protocol, respectively.

19. A program characterized by causing a computer to execute a method for realizing an automobile bus virtual channel executed by a computer according to any one of claims 1 to 6.

Images