Simulation system and device based on virtualized Ethernet card

Abstract

The invention discloses a simulation system and device based on virtualized Ethernet cards, the system comprises N virtualized Ethernet cards vEth and N preset containers, and N is a positive integer; the vEth comprises a communication driving program layer, and the communication driving program layer is used for sending and receiving an Ethernet message through a Raw Socket between an application program and underlying hardware; the preset containers are used for running vEth in the containers based on an application container engine Docker, each preset container corresponds to one vEth, the preset containers are isolated from an external network through a network bridge of the Docker, and the multiple preset containers are connected through the network bridge of the Docker. In the vEth Driver, the raw Socket is created, so that the direct sending and receiving of the Ethernet message are realized.

Description

Technical Field

[0001] This application relates to the field of computers, and in particular, to an emulation system and device based on a virtualized Ethernet network card. Background Art

[0002] Since the 1980s, the automotive electronics field has experienced significant progress. In particular, the rise of electronic control units (ECUs) has made them an indispensable part of modern vehicles. Today, ECUs have penetrated into multiple systems within the vehicle, not only limited to the powertrain system, but also covering multiple fields such as safety, networking, entertainment, and sensing control, and their number can even reach hundreds. These ECUs, together with network technologies such as Ethernet and buses, have constructed a complex distributed network architecture inside the vehicle.

[0003] However, with the increasing complexity of in-vehicle networks, traditional unit or module testing methods can no longer comprehensively verify the functions of the system. Therefore, in order to ensure the stability and reliability of the entire system, more complex and comprehensive system integration testing must be performed. This transformation not only requires higher testing technologies, but also leads to a significant increase in the time required for verification and testing. At the same time, the development of embedded software in test scenarios is significantly dependent on hardware resources. Due to the close association between software and hardware, the development work of upper-layer applications can usually only be carried out after the lower-layer hardware adaptation is completed. This dependency relationship not only increases the development complexity, but also prolongs the overall development cycle. Summary of the Invention

[0004] In view of this, embodiments of this application provide an emulation system and device based on a virtualized Ethernet network card, aiming to solve the problem that the development work of upper-layer applications can only be carried out after lower-layer hardware adaptation.

[0005] In a first aspect, this application provides an emulation system based on a virtualized Ethernet network card, including: N virtualized Ethernet network cards vEth and N preset containers, where N is a positive integer;

[0006] The vEth includes a communication driver layer, and the communication driver layer is used to send and receive Ethernet packets between an application and underlying hardware through a raw socket Raw Socket;

[0007] The preset containers are used to run vEth in containers based on an application container engine Docker. Each preset container corresponds to one vEth. The preset containers are isolated from the external network through the bridge of Docker, and multiple preset containers are interconnected through the bridge of Docker.

[0008] In a possible implementation, the Raw Socket receives Ethernet packets through a preset thread, and the preset thread is used to indicate receiving the Ethernet packets by calling the recv function of the Raw Socket.

[0009] In a possible implementation, the vEth detects in real time through the Raw Socket whether an Ethernet packet is received.

[0010] In a possible implementation, in response to the Raw Socket detecting an Ethernet packet, the vEth is used to notify the application through a first interface function.

[0011] In a possible implementation, in response to the application instructing to send an Ethernet packet, the vEth is used to call a second interface function so that the second interface function fills the header of the data link layer for the Ethernet packet, and the Raw Socket is used to send the filled Ethernet packet to the target location indicated by the Ethernet packet.

[0012] In a possible implementation, the vEth includes a communication service layer, a communication hardware abstraction layer, a communication driver layer, and a Linux Ethernet interface layer.

[0013] The communication service layer is used to provide the interfaces used by the application and interact with the communication hardware abstraction layer through the vEth Interface.

[0014] The communication hardware abstraction layer includes a virtual Ethernet interface vEth Interface for simulating an Ethernet interface in a virtualization environment and interacts with the communication service layer and the communication driver layer through a virtual Ethernet driver vEth Driver.

[0015] The communication driver layer includes interacting with the underlying hardware through the Linux Ethernet interface layer.

[0016] The Linux Ethernet interface layer includes a software interface corresponding to the underlying hardware interface in the Linux operating system and is used to interact with the underlying hardware.

[0017] In a possible implementation, the communication service layer further includes at least one network communication protocol.

[0018] In a possible implementation, the bridge is connected to the network card used by the vEth.

[0019] In a possible implementation, a preset number of vEths are deployed and run on the same Linux device, and interactions between the vEths are achieved through the sending and / or receiving of Ethernet packets.

[0020] In a second aspect, the present application provides an electronic device, which is characterized by comprising: a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, an analog system based on a virtualized Ethernet network card as described in the foregoing first aspect is implemented.

[0021] The analog system based on the virtualized Ethernet network card provided by the present application includes N virtualized Ethernet network cards vEth and N preset containers, where N is a positive integer; the vEth includes a communication driver layer, and the communication driver layer is used to send and receive Ethernet packets between an application program and underlying hardware through a raw socket Raw Socket; the preset containers are used to run vEth in a container based on an application container engine Docker, each preset container corresponds to one vEth, the preset containers are isolated from the external network through the bridge of Docker, and multiple preset containers are interconnected through the bridge of Docker. In the vEth Driver, by creating a Raw Socket, direct sending and receiving of Ethernet packets are realized. This means that the upper-layer software no longer needs to depend on a specific hardware interface, but completes network communication by calling the APIs provided by vEth (such as vEth_Transmit for sending packets and EthIf_RxIndication for receiving packet notifications). The use of RawSocket eliminates the direct dependence of the upper-layer software on the hardware. And through the Docker container technology, an independent running environment is created for each virtual Ethernet network card (vEth). As a lightweight and portable running environment, the Docker container simulates the hardware environment of the ECU, making each vEth run as if it were on a separate ECU. This not only ensures a high similarity between the simulation environment and the real vehicle-mounted network environment, but also realizes the logical isolation between the upper-layer software and the underlying hardware. Through the Docker bridge, the vEths in each container can communicate with each other, simulating the interconnection of multiple ECUs in the vehicle-mounted network and avoiding external network interference at the same time. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] To more clearly illustrate the technical solutions in the embodiments or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0023] Figure 1 It is a schematic internal architecture diagram of vEth provided by an embodiment of the present application;

[0024] Figure 2 Schematic diagram of the vEth operating architecture provided by the embodiments of this application. Specific implementation manners

[0025] It should be noted that the embodiments described in this application are only a part of the embodiments of this application, rather than all embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in this application without creative efforts shall fall within the protection scope of this application.

[0026] To make the following embodiments clear, the background technology related to this application will be introduced first.

[0027] In the prior art, the number of in-vehicle electronic control units (ECUs) has increased sharply with the development of automotive electronics. These ECUs communicate through bus technologies such as Ethernet, CAN, and LIN, jointly building a complex network inside the vehicle. Due to the increase in network complexity, simple unit or module tests can no longer meet the requirements of function verification, and more complex system integration tests must be carried out. However, the existing test methods face the following problems:

[0028] High test cost: Since it is necessary to simulate the interaction between multiple ECUs, traditional physical tests require a large number of hardware devices, resulting in high test costs.

[0029] Long test cycle: Physical tests require building a complex test environment, which takes a long time to prepare, and each modification requires rebuilding the test environment, resulting in a long test cycle.

[0030] Poor test flexibility: Physical tests are difficult to simulate various abnormal situations and fault scenarios, with poor test flexibility.

[0031] Insufficient support for Ethernet emulation: Although some virtualization solutions support the emulation of buses such as CAN and LIN, the support for Ethernet is weak and cannot meet the test requirements of in-vehicle Ethernet communication.

[0032] In response to the problems in the prior art, this application proposes an implementation solution for simulating in-vehicle ECU Ethernet based on the Linux platform. This solution is based on the AUTOSAR specification and realizes the simulation of in-vehicle ECU Ethernet cards under the Linux system. This application has the following beneficial effects:

[0033] Introduction of Virtual Ethernet Network Card (vEth): This application proposes a virtual Ethernet network card vEth, which uses the Raw Socket technology under the Linux system to simulate the Ethernet part of in-vehicle ECUs. vEth can work independently of hardware, allowing upper-layer software development to be independent of actual ECU hardware, thus achieving decoupling of software and hardware. This means that the development of upper-layer applications and underlying hardware can be carried out in parallel, significantly shortening the development cycle.

[0034] Virtualized Testing Environment: This application supports running multiple vEth instances on a single Linux device, and these instances can send and receive Ethernet packets to each other, simulating the scenario where multiple ECUs are interconnected via Ethernet in a real in-vehicle network environment. This not only improves the simulation degree of the testing environment but also facilitates the functional verification of large-scale network systems. By configuring different ECU models and parameters, various complex automotive network environments can be simulated.

[0035] Runtime Architecture Based on Docker: To improve flexibility and isolation, the solution adopts Docker container technology. Each vEth instance runs in an independent container, and network interconnection between containers is achieved through the Docker bridge. This design not only simulates the independent operation of ECUs in the in-vehicle environment but also avoids interference from the external network to the testing environment, making the testing environment closer to the actual in-vehicle network environment.

[0036] Simplifying the Development and Testing Process: By deploying and running vEth in Docker containers, developers can quickly set up and adjust the testing environment, reducing dependence on hardware resources and lowering the cost and time for setting up the testing environment. At the same time, using the compilation toolchain (such as GCC) and debugging tools (such as GDB) on the Linux platform, code compilation, running, and debugging can be carried out efficiently, accelerating the software development and verification process.

[0037] In summary, this solution provides a method for simulating the Ethernet part in the real-time operating system on ECUs under the Linux system by introducing the vEth virtual Ethernet network card and Docker container technology, effectively solving the problem of dependence on hardware in the traditional development and testing process, shortening the development cycle, and improving the accuracy and efficiency of testing.

[0038] Under the framework of the CP (Classic Platform) version of the AUTOSAR (Automotive Open System Architecture) for automotive electronic software architecture, a novel in-vehicle ECU (Electronic Control Unit) Ethernet simulation technology, named vEth, is designed for the Linux operating system environment. The core value of this technology lies in that it breaks the dependence of upper-layer software development on physical ECU hardware, allowing developers to develop and test upper-layer software without actual hardware, significantly improving the flexibility and efficiency of development.

[0039] Among them, AUTOSAR (Automotive Open System Architecture) is the abbreviation of Automotive Open System Architecture. It is an open architecture applied to automotive electronic systems, aiming to improve the reusability of automotive electronic software, reduce development costs, and enhance software security and reliability. AUTOSAR defines a set of methods for developing distributed, function-driven automotive electronic software and a standardization scheme for software architecture on electronic control units (ECUs) for application to different vehicles and platforms.

[0040] The core of the AUTOSAR architecture is a three-layer architecture: the application layer, the runtime environment layer, and the basic software layer. The application layer includes various application software modules, such as engine control, brake control, etc.; the runtime environment layer provides basic functions to support application software, such as task scheduling, memory management, etc.; the basic software layer provides hardware-related driver programs and communication protocol stacks, etc.

[0041] In actual application scenarios, vEth needs to meet the following requirements: ① vEth can send and receive Ethernet packets; ② Multiple vEths can run on the same Linux device, and Ethernet packets can be sent and received between different vEths. Therefore, the above two requirements can be achieved using Raw Socket to implement the simulation of the vEth Driver layer. Because RawSocket has the following characteristics:

[0042] 1. Create a Raw Socket through the network card Eth0. Then, the packets sent through this Raw Socket will not be received by the Eth0 network card.

[0043] 2. Create multiple Raw Sockets through the network card Eth0. Then, the packets sent through these Raw Sockets will be received by other Raw Sockets. That is to say, Raw Sockets created through the same network card can communicate with each other.

[0044] In the simulation system provided by this application, it includes N virtual Ethernet network cards vEth and N preset containers, where N is a positive integer; the vEth includes a communication driver layer, and the communication driver layer is used to send and receive Ethernet packets between the application and the underlying hardware through the raw socket Raw Socket.

[0045] Each vEth contains a communication driver layer, and the main responsibility of this layer is to transmit Ethernet packets between the application and the underlying hardware through Raw Socket. Raw Socket allows the program to communicate directly with the IP layer, bypassing the TCP / UDP layer, thereby realizing the underlying operation of network data. The introduction of vEth makes it possible to simulate physical Ethernet network cards in a virtualized environment, thus realizing the flexible allocation and management of network resources.

[0046] The following uses an embodiment to illustrate the internal architecture of vEth provided by this application. Figure 1 It is a schematic diagram of the internal architecture of vEth provided by the embodiment of this application. This structure realizes the Eth Driver in the AUTOSAR architecture on the Linux system through Raw Socket, and then simulates the network card through Raw Socket to send and receive packets, and consists of the following parts:

[0047] Communication Services: Located at the top layer of the picture, it is the interface for users and applications to access network functions. This layer can include various network communication protocols and services, such as HTTP, FTP, SMTP, etc., but they are not specifically shown in this figure.

[0048] Communication HW Abstraction: This layer is the abstraction and encapsulation of the underlying communication hardware, enabling the upper-layer services to work without directly depending on the specific hardware. This layer includes "vEthInterface".

[0049] Virtual Ethernet Interface (vEth Interface), which is usually used for virtual machine or container networks. It allows virtual machines or containers to communicate with the host or other virtual machines / containers.

[0050] Linux Ethernet Interface used for Ethernet communication in the Linux operating system, which usually corresponds to a physical network interface card (NIC) or a virtual NIC (vNIC).

[0051] Communication Driver: This layer contains drivers that interact with the hardware. It is responsible for converting data packets from the upper layer into a data format that the hardware can understand and sending it to the hardware for processing. The "vEth Driver" and "Raw Socket" in this layer are interfaces that interact with the "Linux Ethernet Interface".

[0052] vEth Driver: This is the driver corresponding to the vEth Interface, which is responsible for handling operations and data transmission related to the vEthInterface.

[0053] Raw Socket: Raw Socket is a raw socket interface provided in the Linux system, which allows applications to directly access the underlying part of the network protocol stack, including Ethernet frames and IP packets.

[0054] When an application needs to send data, it first sends the data to the communication hardware abstraction layer through the communication service layer. In the communication hardware abstraction layer, the data is first encapsulated into Ethernet frames (through the vEth Interface) and then passed to the vEth Interface for further processing. The vEth Driver is responsible for handling operations related to the vEth Interface and sending the data to the underlying hardware (physical or virtual). In the process of receiving data, the process is reversed: the data is read from the hardware, passed to the communication service layer through the vEth Interface and the Linux Ethernet Interface, and finally reaches the application.

[0055] The Linux Ethernet interface layer is the basic network interaction interface for vEth to implement Ethernet simulation in the Linux system, providing a supporting environment for the creation of Raw Sockets and message transmission. In the Linux system, the Ethernet interface is the key channel for data interaction between computers and external networks. For vEth to simulate the Ethernet function of the vehicle ECU, it is the "physical connection point" for vEth to access the system network. Taking the Eth0 network card as an example, a Raw Socket is created based on it. The Linux Ethernet interface layer provides the underlying support for Raw Socket to connect to the system network, allowing vEth to send and receive Ethernet messages in the system network environment and realize network communication.

[0056] When an Ethernet packet enters the Linux system, the Ethernet interface layer first receives the packet. Before the packet is passed to the network layer, the system can check if there is a Raw Socket acting on the data link layer. If so, it sends a copy of the data frame to the relevant Raw Socket receive buffer. This process demonstrates the key role of the Linux Ethernet interface layer in packet processing. It is an important link for packets to enter the system from the external network and be passed to vEth. Moreover, many features of Raw Socket, such as the ability to communicate between multiple Raw Sockets and receive specific types of packets, rely on the support of the Linux Ethernet interface layer. When sending a packet, although Raw Socket needs to assemble the packet itself, the final packet transmission is still through the Linux Ethernet interface layer to interact with the external network; when receiving a packet, it is also through the Ethernet interface layer to receive and forward it to the corresponding Raw Socket, thus realizing the Ethernet packet sending and receiving functions of vEth.

[0057] The above structure clearly shows the positioning and role of vEth in the communication system. The communication driver layer is located between the Ethernet communication interface and the Communication HW Abstraction, provides an interface to the upper layer through the vEth Interface, and interacts with the Linux Ethernet Interface through the vEth Driver at the lower layer, ultimately realizing the sending and receiving of Ethernet packets.

[0058] vEth uses Raw Socket to simulate the sending and receiving functions of an Ethernet card. Raw Socket allows direct reading and writing of packets at the data link layer, enabling upper-layer software to bypass the standard network protocol stack and directly interact with the simulated network layer. This means that when upper-layer software sends or receives packets, it is actually interacting with the virtual network device vEth, rather than a real physical network card. This mechanism effectively decouples the upper-layer application logic from the underlying hardware, making the development and testing of upper-layer software not restricted by hardware.

[0059] In an actual application scenario, the first step is to prepare the system environment. Specifically, first select a platform to ensure it works on the Linux operating system because the Raw Socket function is mainly implemented in the Linux kernel. Then install the necessary components to ensure that the system has the necessary network development libraries and tools, such as the libraries required for socket programming.

[0060] A socket is an abstraction of an endpoint for two-way communication between application processes on different hosts in a network. A RawSocket is a type of socket that can modify the packets in the data link layer of the OSI seven-layer model. Before analyzing RawSocket, it is first necessary to clarify the processing flow when the Linux kernel receives an Ethernet packet. In the Linux kernel, before the Ethernet packet enters the network layer, the system checks whether there is a Raw Socket acting on the data link layer. If there is, the kernel will send a copy of the data frame to the receive buffer of each such socket.

[0061] In a possible implementation, a Raw Socket can be created using the socket(PF_PACKET, SOCK_RAW, htons(ETH_P_XXX)) function, where PF_PACKET indicates an operation at the data link layer, SOCK_RAW represents a raw socket, and ETH_P_XXX is an Ethernet protocol type value. For example, ETH_P_IP represents the IP protocol.

[0062] After creation, the Raw Socket will receive three types of packets: ① data frames sent to the local MAC; ② data frames sent from the local machine; ③ all data frames received when the network card is in promiscuous mode (even for non-local MACs). At the same time, the Socket created in this way will not fill in the relevant headers by packet assembly through the Linux kernel when sending, but needs to assemble the packets by itself through code.

[0063] Since the Raw Socket can receive data frames sent from the local machine, when there are multiple Raw Sockets, the packets sent by Raw Socket 0 will be received by the other Raw Sockets. At the same time, because the packet is an outward-bound packet, the kernel will not pass the packet to the network card either.

[0064] In summary, Raw Socket can meet all the requirements of the vEth Driver layer. The Driver layer of vEth is mainly implemented through Raw Socket. In the initialization stage, a Raw Socket is initialized. For sending Ethernet packets, they are sent through this RawSocket. For receiving Ethernet packets, a thread is created through the Linux thread library to be responsible. This thread will continuously call the recv function of the Raw Socket through an infinite loop to receive the packets received by the Raw Socket. When a packet is received, EthIf_RxIndication() will be called to notify the upper layer.

[0065] For the architecture during the vEth runtime, refer to Figure 2 , Figure 2 which is the schematic diagram of the vEth runtime architecture provided by the embodiments of this application, that is, based on Docker, vEth runs in a container.

[0066] The preset container is used to run vEth in a container based on the application container engine Docker. Each preset container corresponds to a vEth. The preset container realizes isolation from the external network through the bridge of Docker, and multiple preset containers are interconnected through the bridge of Docker.

[0067] Docker is an open-source application container engine. It allows developers to package their applications and dependent packages into a lightweight and portable container, and then publish it to any popular Linux machine, and virtualization can also be achieved. Containers use a sandbox mechanism completely and there will be no interfaces between them.

[0068] Among them, docker_veth is the Docker virtual Ethernet interface, which is used to connect the virtual Ethernet card (vEth) in the container and docker_bridge. The vEth in each container is connected to docker_bridge through the corresponding docker_veth to realize communication between vEts in different containers. For example, vEth0 is connected to docker_bridge through docker_veth, so that vEth0 can send and receive packets with other vEths (such as vEth1, vEth2) connected to docker_bridge through docker_veth, simulating the Ethernet interconnection between in-vehicle ECUs.

[0069] docker_bridge is the virtual bridge in the default bridge network mode of Docker, which has its own IP address, that is Figure 2 172.17.0.1 / 16 in

[0070] The implementation of the vEth Driver part mainly includes three parts:

[0071] Step A1: Create a Raw Socket required for sending and receiving Ethernet packets; create a thread for receiving Ethernet packets, and in the application scenario, the task executed by this thread can be denoted as vEth_recv_task.

[0072] In the initialization phase, the vEth Driver creates two Raw Sockets through system calls, one for sending data and the other for receiving data. Raw Sockets allow user programs to directly send and receive link-layer data packets, skipping the processing of the TCP / IP protocol stack, and are suitable for scenarios that require precise control of network communication details.

[0073] Create a separate thread (vEth_recv_task) to be responsible for listening to the Raw Socket to receive packets. The creation of the thread can involve the use of a thread library (such as the POSIX thread library pthreads). Define the entry function of the thread through the pthread_create function, and this entry function will contain a loop to continuously call recvfrom or a similar function to wait for and process the received packets.

[0074] Step A2: vEth detects whether an Ethernet packet has been received through the Raw Socket.

[0075] The function of receiving packets is implemented in vEth_recv_task. In this task, vEth will detect whether an Ethernet packet has been received through the RawSocket. If a packet is received, it will notify the upper layer through the receiving interface function provided by the upper layer (such as EthIf_RxIndication).

[0076] In a possible implementation, the vEth_Transmit interface encapsulates the logic of packet sending. It receives data from the upper layer, adds necessary link-layer headers (such as source MAC address, destination MAC address, etc.) to it, and then uses the sending function of the RawSocket (such as sendto) to send the constructed packet into the network. This process ensures that the upper layer does not need to care about the details of the link layer, improving the level of abstraction.

[0077] Step A3: vEth provides an interface (vEth_Transmit) for sending packets. When this interface is called, it will fill in the data link-layer header for the Ethernet packet and send the packet through the Raw Socket.

[0078] The vEth_Transmit interface encapsulates the logic of packet transmission. It receives data from the upper layer, adds necessary link layer headers (such as source MAC address, destination MAC address, etc.) to it, and then uses the sending function of Raw Socket (such as sendto) to send the constructed packet into the network.

[0079] The Docker technology is adopted to manage the network of the virtual ECU, and a container is regarded as an ECU. Multiple containers are interconnected through the Docker bridge to simulate the Ethernet interconnection of multiple ECUs in the in-vehicle environment. There are the following advantages to doing so:

[0080] 1. One vEth is exclusive to one container, which is similar to the real situation.

[0081] 2. Isolation from the external network is achieved through the Docker bridge, preventing the vEth from receiving Ethernet packets from the outside world, making the running environment similar to the in-vehicle Ethernet. Since only the network card used by the vEth is connected to the bridge, all packets sent by several vEth can be captured by capturing the packets of the Docker bridge network card.

[0082] In summary, using the vEth Driver to simulate the in-vehicle Ethernet environment brings significant advantages, which are specifically reflected in the following aspects:

[0083] Application of virtualization technology: Through the Docker container technology, an independent running environment is created for each virtual Ethernet card (vEth). As a lightweight and portable running environment, the Docker container simulates the hardware environment of the ECU, making each vEth run as if it were on a separate ECU. This not only ensures a high degree of similarity between the simulation environment and the real in-vehicle network environment, but also realizes the logical isolation between the upper-layer software and the underlying hardware. Through the Docker bridge, the vEths in each container can communicate with each other, simulating the interconnection of multiple ECUs in the in-vehicle network, while avoiding interference from the external network and ensuring the purity of the test environment.

[0084] Raw Socket Technology: In the Linux system, Raw Socket allows direct manipulation of data link layer packets, bypassing the high-level processing of the operating system network protocol stack. In the vEth Driver, by creating a Raw Socket, direct transmission and reception of Ethernet packets are achieved. This means that upper-layer software no longer needs to rely on specific hardware interfaces, but instead completes network communication by calling the APIs provided by vEth (such as vEth_Transmit for packet transmission and EthIf_RxIndication for receiving packet notifications). The use of Raw Socket enables the software layer to be independent of the physical network card, thus eliminating the direct dependence of upper-layer software on hardware.

[0085] Threads and Asynchronous Processing: To handle the reception of network packets, a dedicated receiving thread (vEth_recv_task) is created through the Linux thread library in the solution. This thread calls the recv function of Raw Socket in an infinite loop, continuously listening for network packets. After receiving a packet, it calls the callback function provided by the upper layer (such as EthIf_RxIndication), achieving asynchronous processing of network communication and ensuring the decoupling of upper-layer software and underlying communication processing.

[0086] Thus, this application simulates the in-vehicle Ethernet environment through the vEth Driver, not only solving the problems of high time cost and great implementation difficulty in traditional testing, but also promoting the decoupling of software and hardware and accelerating the software development cycle. This solution provides an efficient and flexible platform for the development, testing, and verification of in-vehicle network systems, facilitating rapid response to market changes and technology upgrade requirements.

[0087] From the description of the above implementation manners, those skilled in the art can clearly understand that all or part of the steps in the above embodiment methods can be implemented by means of software plus a general hardware platform. Based on such an understanding, the technical solution of this application can be embodied in the form of a software product, which can be stored in a storage medium, such as read-only memory (ROM) / RAM, magnetic disk, optical disc, etc., including several instructions for causing a computer device (which can be a personal computer, a server, or a network communication device such as a router) to execute the methods described in each embodiment or some parts of the embodiments of this application.

[0088] It should be noted that in this text, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprising", "including" or any other variant thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device comprising a series of elements not only includes those elements, but also includes other elements not expressly listed, or further includes elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "comprising one..." does not exclude the existence of additional identical elements in the process, method, article or device comprising the said element.

[0089] It should also be noted that the various embodiments in this specification are described in a progressive manner. For the parts that are the same or similar among the various embodiments, reference can be made to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the embodiments of the device and apparatus, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The device and apparatus embodiments described above are only illustrative. The units described as separate components may or may not be physically separated, and the components indicated as units may or may not be physical units, that is, they may be located in one place or distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment. Those of ordinary skill in the art can understand and implement it without creative efforts.

[0090] As described above, this is only a specific implementation manner of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions that can be easily thought of by those skilled in the art within the technical scope disclosed by the present application should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. An analog system based on a virtualized Ethernet network card, characterized in that, Comprising: N virtualized Ethernet network cards vEth and N preset containers, where N is a positive integer; The vEth includes a communication driver layer, and the communication driver layer is used to send and receive Ethernet packets between an application and underlying hardware through a raw socket Raw Socket; The preset containers are used to run vEth in a container based on an application container engine Docker. Each preset container corresponds to one vEth. The preset containers are isolated from the external network through the bridge of Docker, and multiple preset containers are interconnected through the bridge of Docker.

2. The system according to claim 1, characterized in that, The Raw Socket receives Ethernet packets through a preset thread, and the preset thread is used to indicate receiving the Ethernet packets by calling the recv function of the Raw Socket.

3. The system according to claim 1, characterized in that, The vEth detects in real time whether an Ethernet packet is received through the Raw Socket.

4. The system according to claim 3, wherein In response to the Raw Socket detecting an Ethernet packet, the vEth is used to notify the application through a first interface function.

5. The system according to claim 1, wherein In response to the application instructing to send an Ethernet packet, the vEth is used to call a second interface function, so that the second interface function fills a header of a data link layer for the Ethernet packet, and the Raw Socket is used to send the filled Ethernet packet to a target location indicated by the Ethernet packet.

6. The system according to claim 1, characterized in that The vEth includes a communication service layer, a communication hardware abstraction layer, a communication driver layer, and a Linux Ethernet interface layer; The communication service layer is used to provide an interface used by an application and interact with the communication hardware abstraction layer through a vEth Interface; The communication hardware abstraction layer includes a virtual Ethernet interface vEth Interface for simulating an Ethernet interface in a virtualized environment, and interacts with the communication service layer and the communication driver layer through a virtual Ethernet driver vEth Driver; The communication driver layer includes interacting with underlying hardware through the Linux Ethernet interface layer; The Linux Ethernet interface layer includes a software interface corresponding to an underlying hardware interface in a Linux operating system and is used to interact with underlying hardware.

7. The system according to claim 5, characterized in that The communication service layer further includes at least one network communication protocol.

8. The system according to claim 1, wherein The bridge is connected to a network card used by the vEth.

9. The system according to claim 1, wherein The same Linux device deploys and runs a preset number of vEth, and the vEths interact with each other through the sending and / or receiving of Ethernet packets.

10. An electronic device, characterized in that, Comprising: A memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, a simulation system based on a virtualized Ethernet network card as described in any one of claims 1-9 is implemented.

Images