Achievement method and achievement system of automobile bus virtual channel

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 priority to 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 an automobile bus virtual channel. [Background technology]

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

[0004] The present invention relates to a method for implementing an automobile bus virtual channel. The method includes: Designing and launching a single instance server process, then listening on a fixed port of the local computer via UDP (User Datagram 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 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; and The client process's job 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, preferred embodiments of the present invention will be described in detail below in conjunction with the accompanying drawings. [Brief description 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 briefly describes 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 creative efforts. [Figure 1] 1 is a flow chart of a method for implementing an automobile bus virtual channel according to some embodiments. [Diagram 2] FIG. 1 is a principle block diagram of a system for implementing an automobile bus virtual channel according to some embodiments. [Diagram 3] FIG. 1 is a principle block diagram of a system for implementing an automobile bus virtual channel according to some embodiments. [Figure 4] FIG. 1 is a block diagram illustrating the principle of an electronic device according to some embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[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 described clearly and completely below in conjunction with the accompanying drawings, but it is clear that the described embodiments are only some of the embodiments of the present invention and are not 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 labor, belong to the scope of protection of the invention.

[0009] In order to realize the simulation of communication processes of various automotive buses on a computer, virtual hardware support is provided to the bus tool, and bus tool processes of multiple different manufacturers are connected by the virtual hardware to perform real-time communication. In related vehicle software development technology, a driver program is generally created to control data transmission of the virtual bus at the system bottom layer, and multiple bus tool processes are connected through the virtual hardware to perform real-time communication. However, the method of controlling data transfer of the virtual bus by creating a driver program has the following problems. 1) After the driver program is installed, it cannot be used until the computer is restarted, and it cannot be used immediately after opening. 2) The driver program and the software system are tightly bound together. If a driver program is created on a Windows system to realize a virtual channel, the driver program cannot run on a Linux system, and portability is poor. 3) The driver program has poor update capability, that is, even if the driver program supports virtual channels of CAN bus and LIN bus, it cannot be automatically upgraded to support new virtual channels of FlexRay bus and Ethernet.

[0010] Therefore, at least one embodiment provides a method for realizing an automobile bus virtual channel, which includes: creating a server process as a provider of a virtual channel, and listening to a fixed port of a local computer by UDP protocol after starting up; creating at least one client process, and making each client process instance a virtual channel user, and listening to a random port of a local computer by UDP protocol after starting up; the client process sends a registration request packet to the server process, and the server process feeds back a successful signal to the client process after successfully receiving the registration request packet, and the client process sends a heartbeat packet to the server process at a specific interval time after receiving the feedback, and the server process waits for a response to the heartbeat packet; the client process sends an automobile bus message to the server process; if 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 the remaining client processes, and modifies a direction attribute of the automobile bus message to receiving.

[0011] The provider of the virtual channel 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 satisfying the demand for real-time simulation.

[0012] Various non-limiting embodiments of illustrative 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 a virtual channel, and after being started, a fixed port of a local computer is intercepted by a UDP protocol. At least one client process is created, and each client process is a user of a virtual channel, and after being started, each client process is intercepted by a random port of a local computer by a UDP protocol. In step S102, 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 was 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. 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 of the auto bus message, and modifies the direction attribute of the auto bus message to send, and at the same time 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 of an automobile CAN network communication as an example, the implementation method of 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 provider of the virtual channel. After the server process is started, it starts its own UDP server and listens on a fixed port, e.g. 11898. Then, according to the 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, and is specifically as follows: An independent process "Chassis1.exe" is created to simulate the behavior of the ECU on the automobile chassis, and the process is a client process of the CAN bus virtual channel, that is, a user of the virtual channel. After the client process is started, it starts its own UDP server and listens to a random port, such as 50000.

[0016] The following description corresponds to step S102 in some embodiments. After the client process has been successfully started, 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 one client process instance. The client process instance includes a client process UDP interception port 50000 and a counter AliveCounter (initial value is the maximum allowable value, e.g., 10) for the client process to maintain a heartbeat. The client process instance is then added to a data delivery queue grouped by channel. After the addition is completed, 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, a frequency of sending 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. Next, 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 a 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 a server process, and the data transmission / reception packet is encoded by a compression and encryption method. The data transmission / reception packet contains attributes of the CAN bus message, such as the channel index, Id, data length, data bytes, etc. 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 contained in the CAN bus message to the timestamp actively obtained by the server process after receiving the CAN bus message. Then, the data delivery stage 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 and obtains the CAN bus message with the latest time stamp, so that the client process knows at what time the CAN bus message it sent is 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 and obtains the CAN bus message with the latest time stamp, 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 the other 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 of creating a server process are described in detail using the server process program “VirtualCANServer.exe” of the Windows end independent CAN bus virtual channel provider as an example. After the server process program "VirtualCANServer.exe" is started, it calls the mutual exclusion API function "CreateMutex" provided by the software system to create a mutual exclusion with the name of the server process program "VirtualCANServer" as the mutual exclusion name, and then obtains the error code by 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 has failed, and the server process program is terminated. 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 sniff any random port on the local computer, and if the sniffing fails, it attempts to sniff other random ports on the local computer until it succeeds.

[0021] Taking the user's client process program “Chassis1.exe” of the CAN bus virtual channel on the Windows side as an example, creating at least one client process will be described in detail. After the client process program "Chassis1.exe" is started, 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 keep trying to listen on the port until it is successfully listened on. Assuming that the port that is successfully listened on is 12345, the client process program enters into a normal operating state and keeps listening on the port.

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

[0023] In some embodiments, after the client process is successfully started, 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 successfully registers with the server process, it sends a heartbeat maintaining UDP packet to the server process's port 11898. The heartbeat maintaining UDP packet has 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 and includes: After the server process starts, it reads and stores the current system performance counter values ​​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 counters.

[0025] A timestamp must be set for the server process to process a bus message. On a Windows platform, when the server process starts, it calls the QueryPerformanceFrequency system API function to get the frequency of the system performance counter and stores it in variable F. It also calls the QueryPerformanceCounter system API function to get 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 to the CAN bus is successfully responded to on the bus, the timestamp of the message is determined, and all ECUs that receive the message will obtain 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, the computer device configured to execute a client process and a server process. The client process, as a user of the virtual channel, is configured to send registration request packets to the server process, send heartbeat packets to the server process based on a specific interval time, and send car bus messages to the server process. The server process, as a virtual channel provider, 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 of the automobile bus message and modifying it to send a directional attribute of the automobile bus message, and at the same time to send this automobile bus message to other client processes and modify it to receive a directional attribute of the automobile bus message.

[0028] As shown in Figure 3, some embodiments further provide a system for implementing an automobile bus virtual channel, the system including 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. The client process, as a user of the virtual channel, is configured to send registration request packets to the server process, send heartbeat packets to the server process based on a specific interval time, and send car bus messages to the server process. The server process, as a virtual channel provider, 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 of the automobile bus message and modifying it to send a directional attribute of the automobile bus message, and at the same time to send this automobile bus message to other client processes and modify it to receive a directional 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. For specific details, the content of the above-mentioned method for realizing the automobile bus virtual channel can be referred to, so the description is 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 a virtual channel, and listen to a fixed port of a local computer after starting up; Create at least one client process, and each client process as a user of a virtual channel, and listen to a random port of a local computer after starting up; The client process sends a registration request packet to the server process, and the server process feeds back the successful reception of a signal to the client process after successfully receiving the registration request packet, and the client process sends a heartbeat packet to the server process at a specific interval time after receiving the feedback, and the server process waits for a response to the heartbeat packet; The client process sends an automobile bus message to the server process. If the transmission 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 send, and at the same time sends the automobile bus message to another client process, and modifies a direction attribute of the automobile bus message to receive.

[0030] In some embodiments, creating a server process includes: attempting to create a mutually exclusive amount named by the server process program after the server process program is started, 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; and listening to a fixed port of the local computer after the program is started, and if the listening fails, the process program is terminated and the mutually exclusive amount is released.

[0031] In some embodiments, creating at least one client process includes: after the at least one client process program is started, attempting to sniff any random port of the local computer, and if the sniffing fails, attempting to sniff other random ports of the local computer until the sniffing succeeds;

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

[0033] In some embodiments, the server process sets the timestamp of the car bus message, and includes the following: 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 considered as types of electronic equipment.

[0035] The configuration shown in FIG. 3 is not intended to be limiting of 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, USB port, 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. Among them, the readable storage medium or computer-readable storage medium includes at least one type 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 installed in the computer device, a Smart Media Card (SMC) (registered trademark), a Secure Digital Card (SD), a Flash Card, etc. Furthermore, the memory may include both the internal storage unit of the computer device and an external storage device. The memory is used to store various data such as application software and computer program codes 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 for executing program code stored in memory or processing data, e.g., executing a computer program.

[0038] In some embodiments, the communication bus may be an I / O 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 an input unit such as a display, a keyboard, etc., and optionally the user interface may also include a standard wired interface, a wireless interface. Optionally, in some embodiments, the display may be an LED display, a liquid crystal display, a touch-type 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, for displaying information processed in the computer device and for displaying a visualized user interface.

[0040] When the processor executes the program, it realizes the steps in the embodiment of the method for realizing an automobile bus virtual channel shown in Fig. 1, for example steps S101 to S103 shown in Fig. 1. Alternatively, when the processor executes the computer program, it realizes 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 and made a provider of a virtual channel. After it is started, it listens on 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 a virtual channel, and after being started, each client process listens at a random port of a local computer by using a UDP protocol. 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 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. A client process sends an automobile bus message to a server process, and if the sending is successful, the server process returns to the client process after setting a timestamp of the automobile bus message, and modifies the 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.

[0042] Optionally, as a possible embodiment, the processor is further used to realize the following steps: Creating a server process (steps) includes the following: 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, as a possible embodiment, the processor is further used to realize the following steps: Creating at least one client process includes: After each client process program is started, it attempts to sniff any random port on the local computer, and if the sniffing fails, it attempts to sniff other random ports on the local computer until it succeeds.

[0044] Optionally, as a possible embodiment, the processor is further used to realize 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, as a possible embodiment, the processor is further used to realize the following steps: The server process setting a timestamp for an automobile bus message includes: After the server process starts, it reads and stores the current system performance counter values ​​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 counters.

[0046] Some embodiments further provide a computer-readable storage medium, which stores a program for implementing an automobile bus virtual channel in the computer-readable storage medium. When the program is executed by a processor, the specific steps of the method for implementing an automobile bus virtual channel can be implemented. However, the specific description of the method for implementing an automobile bus virtual channel may be referred to, and the description will be omitted here.

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

[0048] In the vehicle development and debugging system of some embodiments, the specific method for implementing the vehicle bus virtual channel is similar to the above-mentioned method for implementing the vehicle bus virtual channel, and thus the description is omitted here.

[0049] In some embodiments of the present invention, it is to be understood that the disclosed apparatus and method may be realized in other manners. The above-described apparatus embodiments are merely illustrative, and for example, the flowcharts and block diagrams in the drawings illustrate possible architectures, functions, and operations of the apparatus, methods, and computer program products according to some embodiments of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, a program segment, or a part of code. The module, the program segment, or the part of code includes executable instructions for implementing one or more predetermined logical functions. It is to be noted that in some alternative implementations, the functions depicted in the blocks may occur in a different order than the order depicted in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and may sometimes be executed in a reverse order depending on the functions involved. It is also to be noted that each block of 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 executes a predetermined function or operation, or may be implemented in a combination of dedicated hardware and computer instructions.

[0050] In addition, 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 together 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 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 method according to each embodiment of the present invention.

[0052] The above-mentioned 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 contents of the specification, but should be determined based on 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 method for realizing an automobile bus virtual channel, comprising: a client process sending an automobile bus message to a server process; when the sending is successful, the server process returning to the client process after setting a timestamp of the automobile bus message, and modifying a direction attribute of the automobile bus message to sending; and at the same time sending the automobile bus message to another client process, and modifying the direction attribute of the automobile bus message to receiving.

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 method for realizing 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 The method for realizing an automobile bus virtual channel according to claim 1, further comprising: 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 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 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 method for implementing an automobile bus virtual channel as claimed in claim 1, characterized in that after each client process is started, it listens on a random port of the local computer by using UDP protocol or 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. 1. A computer program product comprising: Contains computer programs or commands, A computer program product, comprising the steps of: (a) executing the computer program or the command on a computer to cause the computer to execute the method for realizing an automobile bus virtual channel according to any one of claims 1 to 6.

Images