A Method for Constructing an Embedded Software Simulation and Testing Environment Based on a Virtual Machine

Abstract

This invention relates to a method for constructing an embedded software simulation testing environment based on a virtual machine, belonging to the field of embedded software testing technology. This method adds an interface adaptation layer and a network communication layer, replacing the drivers of the underlying dedicated hardware interface devices or buses, redirecting the operations of these devices or buses to network communication operations, thereby enabling the deployment of an embedded software virtual machine environment. By replacing external real interconnected devices or systems with simulation devices, it provides stimulus or response data for the embedded software operation, while simultaneously receiving embedded software output data and providing real-time automatic responses based on the output data, ensuring uninterrupted operation of the embedded software. Through a test driver, it centrally manages external simulation devices and schedules them according to business processes to collaboratively complete automated embedded software testing.

Description

Technical Field

[0001] This invention belongs to the field of embedded software testing technology, specifically relating to a method for constructing an embedded software simulation testing environment based on a virtual machine. Background Technology

[0002] An embedded system is a specialized computer system designed for specific application needs and operating environments. It involves building an embedded hardware platform and developing corresponding embedded software to perform various control, computation, monitoring, and communication tasks. Embedded systems are widely used in many fields, including aerospace, industrial process control, and consumer electronics.

[0003] Embedded systems typically exhibit characteristics such as platform-specificity and external interconnection device specificity. Platform-specificity means that embedded software cannot function properly before the embedded hardware platform is developed; external interconnection device specificity means that embedded software requires interaction with its interconnected external devices or systems to achieve its intended functions. These platform-specific and external device specificity characteristics present significant difficulties and challenges for embedded software testing. On the one hand, due to the lack of external interconnection devices or systems, it is impossible to build a complete embedded software configuration or system test environment. Software testing cannot cover the timing and interfaces of the embedded software, making it difficult to guarantee test adequacy. On the other hand, deploying embedded software to a real-world environment for configuration or system testing cannot provide the execution conditions for extreme or abnormal test cases, such as simulating excessive actions or inputs outside the boundary range. Moreover, the execution of such extreme or abnormal test cases is highly likely to damage hardware, resulting in high error and correction costs. Furthermore, due to various resource limitations, the effective time that the actual environment can provide for software testing is also very limited; the characteristics of embedded systems, such as strong real-time requirements, high reliability and security requirements, specific timing and information interaction characteristics between external interconnected devices, and difficulty in triggering and simulating abnormal or error scenarios, also make embedded software testing more difficult. Summary of the Invention

[0004] (a) Technical problems to be solved

[0005] The technical problem to be solved by this invention is: how to build an embedded software simulation test environment based on virtual machines and simulation devices, decouple the specificity of the embedded software running platform from the specialization of external interconnection devices, provide embedded software testers with a flexible and controllable simulation test environment, support automated testing of embedded software, and meet the software testing needs of various normal or abnormal scenarios.

[0006] (II) Technical Solution

[0007] To address the aforementioned technical problems, this invention provides a method for constructing an embedded software simulation testing environment based on a virtual machine. This method designs the embedded software simulation testing environment to consist of three parts: a virtual target machine, external simulation devices, and a test driver. The virtual target machine provides an operating environment for the embedded software that does not rely on a dedicated embedded hardware platform. The external simulation devices interact with the virtual target machine, providing simulated external interconnected devices or systems for embedded software testing, i.e., companion devices or systems. The test driver provides automated support for embedded software testing, centrally manages and controls the external simulation devices, schedules the external simulation devices according to the test flow described in the test script, and collaboratively completes automated embedded software testing.

[0008] The present invention also provides an embedded software simulation testing environment constructed based on the method described above.

[0009] (III) Beneficial Effects

[0010] (1) By adding an interface adaptation layer and a network communication layer, the driver of the underlying specific dedicated hardware interface device or bus is replaced, and the operation of the specific dedicated hardware interface device or bus is redirected to network communication operation. This eliminates the procurement and development of dedicated hardware interface devices and reduces the cycle and cost of building the embedded software simulation test environment.

[0011] (2) By deploying and running the embedded software virtual machine environment, the limitations of the specificity of the embedded software running platform are eliminated, the portability of the embedded software simulation test environment is improved, and the rapid deployment and sharing of the embedded software simulation test environment can be realized.

[0012] (3) The embedded software interface protocol is described by the data model and the embedded software interaction behavior is described by the interaction model. This enables the simulation of the external interconnection device or system function of the embedded software based on the interface data, which reduces the complexity of building the embedded software simulation test environment.

[0013] (4) By providing simulation equipment management and control interfaces, the ability to control external simulation equipment is enhanced, and the flexibility and controllability of embedded software testing are improved.

[0014] (5) By describing tests through scripts, it supports automated testing of embedded software according to business processes, which improves the effectiveness and efficiency of embedded software testing;

[0015] (6) Through the simulation device registration center, the test driver and the specific external simulation device are completely decoupled, realizing the generalization of the test driver. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the embedded software simulation testing environment and its technical principles according to the present invention.

[0017] Figure 2 This is a schematic diagram of the external simulation device and its technical principles.

[0018] Figure 3 This is a schematic diagram of the test driver and its technical principles according to the present invention. Detailed Implementation

[0019] To make the objectives, contents, and advantages of the present invention clearer, the specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples.

[0020] This invention provides a method for constructing an embedded software simulation testing environment based on a virtual machine. This method adds an interface adaptation layer and a network communication layer, replaces the drivers of the underlying dedicated hardware interface devices or buses, and redirects the operations of these devices or buses into network communication operations, thereby enabling the deployment of an embedded software virtual machine environment. The method uses simulation devices to replace external real interconnected devices or systems, providing stimulus or response data for the embedded software operation, while simultaneously receiving embedded software output data and providing real-time automatic responses based on the output data, ensuring uninterrupted operation of the embedded software. Through a test driver, external simulation devices are centrally managed, and the simulation devices are scheduled for testing according to business processes, collaboratively completing automated testing of the embedded software.

[0021] The composition and technical principle diagram of the virtual machine-based embedded software simulation test environment are shown below. Figure 1 As shown, the embedded software simulation test environment consists of three parts: a virtual target machine, external simulation devices, and test drivers. The virtual target machine provides an operating environment for the embedded software that does not rely on a dedicated embedded hardware platform; the external simulation devices provide simulation of external interconnected devices or systems for embedded software testing, i.e., companion devices or systems; and the test drivers provide automated support for embedded software testing. The following details the specific steps for constructing the embedded software simulation test environment.

[0022] Step 1: Deployment of Embedded Software Virtual Target Machine

[0023] Embedded software virtual target machine deployment involves adding an interface adaptation layer and a network communication layer, replacing the drivers of the underlying specific dedicated hardware interface devices or buses, decoupling the embedded software's dependence on dedicated hardware interfaces, and providing a virtual target machine-based operating environment for embedded software.

[0024] The interface adaptation layer redirects access operations from the upper-layer embedded software to specific hardware interface devices or buses into ordinary network communication operations by adapting dedicated hardware interface operation functions. From the perspective of ensuring the operation of the embedded software, the embedded software only needs to obtain the same operational effect through the dedicated hardware interface operation functions and is neither aware of nor concerned with the actual operation process of the underlying hardware interface. There are two implementation methods for the interface adaptation layer:

[0025] (1) Maintain the hardware interface function prototype and redirect the dedicated hardware interface operations to the corresponding operations of the network communication layer by redefining the function implementation part.

[0026] (2) Register the corresponding operation functions of the network communication layer to the operating system I / O system, so that the redirection of the dedicated hardware interface operation to the corresponding operation of the network communication layer can be automatically completed through standard I / O operations (such as device registration, device start / stop, device reset and exit, device interrupt, device read / write, etc.).

[0027] The network communication layer primarily enables communication and interaction between embedded software and external systems or devices. It receives stimulus data from external systems or devices and outputs response or feedback data to them. The network communication layer is implemented using a TCP / UDP server model, employing select for multiplexing to manage connections and data reception from all external TCP / UDP clients.

[0028] Step 2: Construction of External Simulation Equipment

[0029] External simulation equipment is primarily used to replace real external interconnected devices or systems for embedded software. It provides stimulus or response data for the embedded software's operation, receives output data from the embedded software, and provides real-time automatic responses based on the output data, ensuring uninterrupted operation of the embedded software and supporting testing of the embedded software according to business processes. External simulation equipment consists of three layers: a network communication layer, a functional simulation layer, and a device control layer. Figure 2 As shown.

[0030] (1) Network communication layer

[0031] The network communication layer primarily handles communication and interaction with the virtual target machine's network communication layer. Since the virtual target machine's network communication layer uses a TCP / UDP server mode and employs select for multiplexing, the external simulation device's network communication layer uses a TCP / UDP client mode. This client mode is responsible for sending network data to the virtual target machine, receiving output data from the virtual target machine, and receiving control functions from the external simulation device's device control layer, such as establishing and disconnecting connections and sending data.

[0032] (2) Functional Simulation Layer

[0033] The functional simulation layer primarily implements the functional simulation of externally connected devices or systems for embedded software, mainly simulating the input, output, and interaction timing of the actual connected devices or systems. The "functional simulation layer" of the external simulation device includes four parts: simulation model, data frame parser, command frame responder, and data frame encoder.

[0034] The simulation model mainly includes a data model and an interaction model. The data model describes the embedded software interface protocol and is the basis for parsing and recognizing request commands, as well as constructing stimulus and response commands. The interaction model describes the interactive behavior of the embedded software and is the basis for realizing real-time response processing. The data frame parser, based on the data model, parses and recognizes request commands from the embedded software output data. The command frame responder, based on the interaction model, completes the real-time response processing of embedded software request commands (embedded software output data). The data frame encoder, based on the data model, constructs embedded software stimulus and response commands (embedded software input data).

[0035] (3) Equipment control layer

[0036] The device control layer primarily provides management and control interfaces for the simulation equipment. It employs remote call technology to publish relevant management and control functions for the external simulation equipment as callable interface functions. These functions include retrieving simulation equipment information, retrieving the simulation equipment data model, turning the device on / off, enabling / disabling automatic response functions, enabling / disabling automatic status feedback functions, sending command frames, and preparing command frames.

[0037] Step 3: Test Driver Construction

[0038] The test driver is primarily used for centralized management and control of external simulation devices. It schedules these devices according to the test flow described in the test scripts, collaboratively completing automated embedded software testing. The test driver consists of four parts: a script engine, a general function library, simulation device-related function libraries, and a simulation device registry center. Figure 3 As shown.

[0039] The script engine primarily interprets and executes test scripts, which is key to automating embedded software testing. The general function library provides common operation functions for test scripts, such as file operations (opening files, reading data, writing data, closing files, etc.), string operations (string concatenation, string truncation, getting string length, getting characters at specific positions, etc.), and mathematical operations (trigonometric functions, square root functions, finding maximum and minimum values, generating random numbers, etc.).

[0040] The simulation device-related function library provides test scripts with interface functions for operating the simulation device. These interface functions are encapsulations of the interface functions published by the external simulation device's "device control layer," such as obtaining simulation device information, obtaining the simulation device data model, turning the device on / off, turning the automatic response function on / off, turning the automatic status feedback function on / off, sending command frames, and preparing command frames. By calling these interface functions, on the one hand, external simulation device information can be obtained, and then control commands and stimulus commands can be sent to the simulation device according to the simulation device identifier to control the behavior of the simulation device; on the other hand, external simulation device data model can be obtained, and then response or stimulus data that meets the simulation device's receiving requirements can be constructed according to the simulation device data model.

[0041] The simulation device registry center primarily enables centralized management and maintenance of external simulation devices. Based on the name of the external simulation device, the registry center queries for the device's proxy object, and then uses this proxy object to invoke the actual external simulation device, thereby acquiring its status or controlling its behavior.

[0042] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for constructing an embedded software simulation and testing environment based on a virtual machine, characterized in that, In this method, the embedded software simulation test environment is designed to consist of three parts: a virtual target machine, an external simulation device, and a test driver. The virtual target machine provides an operating environment for the embedded software that does not depend on a dedicated embedded hardware platform. The external simulation device interacts with the virtual target machine and provides simulated external interconnection devices or systems for embedded software testing, i.e., test companion devices or systems. The test driver provides automated support for embedded software testing, centrally manages and controls external simulation devices, schedules external simulation devices according to the test process described in the test script, and collaboratively completes automated embedded software testing. In this method, the deployment of the embedded software virtual target machine is achieved by adding an interface adaptation layer and a network communication layer, replacing the driver of the underlying specific dedicated hardware interface device or bus, decoupling the embedded software's dependence on dedicated hardware interfaces, and providing the embedded software with a runtime environment based on the virtual target machine; The interface adaptation layer redirects the access operations of the upper-layer embedded software to specific hardware interface devices or buses to ordinary network communication operations by adapting dedicated hardware interface operation functions. From the perspective of ensuring the operation of embedded software, the embedded software only needs to obtain the same operation effect through dedicated hardware interface operation functions, and does not perceive or care about the actual operation process of the underlying hardware interface. The network communication layer enables communication and interaction between the embedded software and external systems or devices. On the one hand, it receives stimulus data from external systems or devices, and on the other hand, it outputs response or feedback data to external systems or devices. The network communication layer is implemented in a TCP / UDP server mode, using select to achieve multiplexing and manage the connection and data reception of all external TCP / UDP clients. The external simulation device provides stimulus or response data for the embedded software to run, and at the same time receives the output data of the embedded software and responds automatically in real time based on the output data, ensuring that the embedded software runs continuously and supporting the embedded software to carry out testing according to the business process. The test driver consists of four parts: a script engine, a general function library, a simulation device-related function library, and a simulation device registry center. The script engine interprets and runs test scripts to automate embedded software testing; the general function library provides common operation functions for test scripts. The simulation equipment-related function library provides test scripts with interface functions for operating the simulation equipment. These interface functions are encapsulations of the interface functions published by the device control layer of the external simulation equipment. By calling these interface functions, it is possible to obtain information about the external simulation equipment and then send control commands and stimulus commands to the simulation equipment according to the simulation equipment identifier to control the behavior of the simulation equipment. On the other hand, it can acquire the data model of external simulation equipment, and then construct response or stimulus data that meets the receiving requirements of the simulation equipment according to the data model of the simulation equipment. The simulation device registry center enables centralized management and maintenance of external simulation devices. Based on the name of the external simulation device, the registry center queries the proxy object of the external simulation device, and then calls the real external simulation device through the proxy object to complete the acquisition of the external simulation device's status or behavior control.

2. The method as described in claim 1, characterized in that, The interface adaptation layer can be implemented in two ways: (1) Maintain the hardware interface function prototype and redirect the dedicated hardware interface operations to the corresponding operations of the network communication layer by redefining the function implementation part; (2) Register the corresponding operation functions of the network communication layer to the operating system I / O system, so as to automatically redirect the dedicated hardware interface operation to the corresponding operation of the network communication layer through the I / O standard operation. The I / O standard operation includes device registration, device start / stop, device reset and exit, device interrupt, and device read / write.

3. The method as described in claim 1, characterized in that, The external simulation device consists of three layers: a network communication layer, a functional simulation layer, and a device control layer. The network communication layer of the external simulation device enables communication and interaction with the network communication layer of the virtual target machine. The network communication layer in the virtual target machine adopts a TCP / UDP server mode and uses select to achieve multiplexing. The network communication layer of the external simulation device adopts a TCP / UDP client mode. On the one hand, it is responsible for sending network data to the virtual target machine and receiving output data from the virtual target machine. On the other hand, it receives control from the device control layer of the external simulation device, including establishing connections, disconnecting connections, and sending data. The functional simulation layer realizes the functional simulation of the external real cross-linked device or system of the embedded software, and simulates the input, output and interaction timing of the real cross-linked device or system. The device control layer provides management and control interfaces for the simulation device to external systems. The device control layer is implemented using remote call technology, which publishes the relevant functions for managing and controlling external simulation devices as interface functions that can be called externally.

4. The method as described in claim 3, characterized in that, The functional simulation layer of the external simulation device includes a simulation model, a data frame parser, a command frame responder, and a data frame encoder. The simulation model includes a data model and an interaction model. The data model describes the embedded software interface protocol and is the basis for parsing and recognizing request commands, as well as constructing stimulus and response commands. The interaction model describes the interactive behavior of the embedded software and is the basis for realizing real-time response processing. The data frame parser, based on the data model, parses and recognizes request commands from the output data of the embedded software. The command frame responder is based on an interactive model and completes real-time response processing for embedded software request commands. The data frame encoder is based on a data model to construct embedded software stimulus and response commands.

5. An embedded software simulation test environment constructed based on the method described in any one of claims 1 to 4.

Images