WO2023230883A1 - 一种测试方法、***及装置 - Google Patents
一种测试方法、***及装置 Download PDFInfo
- Publication number
- WO2023230883A1 WO2023230883A1 PCT/CN2022/096367 CN2022096367W WO2023230883A1 WO 2023230883 A1 WO2023230883 A1 WO 2023230883A1 CN 2022096367 W CN2022096367 W CN 2022096367W WO 2023230883 A1 WO2023230883 A1 WO 2023230883A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- fault
- hardware
- module
- computer
- fault injection
- Prior art date
Links
- 238000012360 testing method Methods 0.000 title claims abstract description 175
- 238000002347 injection Methods 0.000 claims abstract description 312
- 239000007924 injection Substances 0.000 claims abstract description 312
- 238000000034 method Methods 0.000 claims abstract description 71
- 238000004088 simulation Methods 0.000 claims description 97
- 238000012545 processing Methods 0.000 claims description 29
- 238000010586 diagram Methods 0.000 claims description 22
- 238000004458 analytical method Methods 0.000 claims description 16
- 230000006870 function Effects 0.000 claims description 16
- 238000004891 communication Methods 0.000 claims description 15
- 230000008569 process Effects 0.000 claims description 13
- 238000013519 translation Methods 0.000 claims description 13
- 238000004590 computer program Methods 0.000 claims description 12
- 230000003993 interaction Effects 0.000 claims description 10
- 238000005259 measurement Methods 0.000 claims description 8
- 238000011084 recovery Methods 0.000 claims description 7
- 230000009471 action Effects 0.000 claims description 4
- 230000002093 peripheral effect Effects 0.000 claims description 3
- 230000003068 static effect Effects 0.000 claims description 3
- 238000004519 manufacturing process Methods 0.000 claims description 2
- 230000003287 optical effect Effects 0.000 claims 5
- 238000003491 array Methods 0.000 claims 3
- 230000005540 biological transmission Effects 0.000 claims 3
- RYGMFSIKBFXOCR-UHFFFAOYSA-N Copper Chemical compound [Cu] RYGMFSIKBFXOCR-UHFFFAOYSA-N 0.000 claims 1
- 229910052802 copper Inorganic materials 0.000 claims 1
- 239000010949 copper Substances 0.000 claims 1
- 230000001419 dependent effect Effects 0.000 claims 1
- 230000000694 effects Effects 0.000 claims 1
- 239000000835 fiber Substances 0.000 claims 1
- 239000004065 semiconductor Substances 0.000 claims 1
- 238000006467 substitution reaction Methods 0.000 claims 1
- 238000005516 engineering process Methods 0.000 description 6
- 238000012795 verification Methods 0.000 description 6
- 238000012986 modification Methods 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 230000006399 behavior Effects 0.000 description 3
- 230000008859 change Effects 0.000 description 3
- 238000013507 mapping Methods 0.000 description 3
- 230000036961 partial effect Effects 0.000 description 3
- 230000004044 response Effects 0.000 description 3
- 239000008186 active pharmaceutical agent Substances 0.000 description 2
- 238000004422 calculation algorithm Methods 0.000 description 2
- 230000002452 interceptive effect Effects 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 230000001133 acceleration Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 230000009194 climbing Effects 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 230000000670 limiting effect Effects 0.000 description 1
- 230000007257 malfunction Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 230000002829 reductive effect Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 238000010998 test method Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
Definitions
- the present application relates to the field of testing technology, and in particular, to a testing method, system and device.
- fault injection is to use a certain strategy to artificially introduce faults of this fault type into the target system for a specified fault type, so as to observe and analyze the operating behavior of the target system under the condition of injected faults.
- Fault injection is an important means to achieve safe and realistic simulation of various fault scenarios in the system. Fault injection plays a very important role in the integration and testing process of embedded software and hardware systems such as automotive electronics. Especially in safety-critical systems, comprehensive and sufficient fault testing is an important guarantee for the reliable operation of the system.
- Safety-critical systems are generally composed of software and hardware, so fault injection testing is also performed from both software and hardware aspects.
- Commonly used fault injection techniques are divided into two categories, namely software-based fault injection and hardware-based fault injection.
- software-based fault injection has the problems of high cost and low efficiency, while software-based fault injection cannot cover hardware faults. How to flexibly and comprehensively implement fault injection at the software level and hardware level has become an urgent problem to be solved.
- a testing method, system and device are proposed that can flexibly and comprehensively implement fault injection at the software level and hardware level.
- embodiments of the present application provide a testing method, which method is applied to a virtualization software and hardware platform.
- the virtualization software and hardware platform includes a virtualization hardware module and an embedded software module, wherein the virtualization software and hardware platform includes a virtualization hardware module and an embedded software module.
- the hardware module is used to represent a virtualized embedded hardware system that can run on a general-purpose computer.
- the method includes: obtaining fault injection configuration information, the fault injection configuration information is used to indicate the fault injection point and fault type, the The fault injection point is located in the virtualized hardware module or the embedded software module; fault injection is performed to the fault injection point according to the fault type.
- testing methods provided by the embodiments of this application can be applied to the testing and verification of any electronic control system that combines software and hardware, including automotive electronic control systems, robot electronic control systems, etc.
- a virtualized embedded hardware system that can run on a general-purpose computer is used to replace the actual hardware device, thereby reducing the testing cost; fault injection into the virtualized embedded hardware system is just like software fault injection. Injection is equally flexible, thereby improving hardware fault test coverage.
- the method further includes: dynamically translating binary execution instructions of the embedded hardware system into binary execution instructions that can be run on a general-purpose computer, and obtain the Describe the virtualization hardware module.
- virtualization of the embedded hardware system is achieved through dynamic translation of binary execution instructions, thereby reducing test costs and improving flexibility and coverage.
- the binary execution instructions of the embedded hardware system are dynamically translated into binary execution instructions that can be run on a general-purpose computer.
- Instructing to obtain the virtualized hardware module includes: according to test requirements, determining a target binary execution instruction from binary execution instructions of the embedded hardware system and performing the dynamic translation to obtain the virtualization hardware module.
- the method further includes: after performing the fault injection, generating a control signal;
- the control signal is sent to the controlled object simulation platform, so that the controlled object simulation platform performs performance simulation on the controlled object according to the control signal, and obtains fault test feedback results.
- the method further includes: receiving the fault test feedback result; sending the fault feedback result to the fault Inject the console so that the fault injection console performs fault analysis based on the fault test feedback results and the preconfigured expected fault processing results.
- performing fault injection into the fault injection point according to the fault type includes: : According to the fault type, perform hardware fault injection to the fault injection point located in the virtualized hardware module by modifying the calibration protocol or the universal measurement and calibration protocol.
- hardware fault simulation can be realized by modifying the calibration protocol or the general measurement and calibration protocol.
- the method according to the Injecting a fault into the fault injection point according to the fault type includes: injecting a software fault into the fault injection point located in the embedded software module through code injection or state injection according to the fault type.
- software fault simulation can be achieved through code injection or state injection.
- test system includes: a fault injection console and a virtualization software and hardware platform.
- the virtualization software and hardware platform includes a virtualization hardware module and an embedded software module. , wherein the virtualization hardware module is used to represent a virtualized embedded hardware system that can run on a general-purpose computer;
- the fault injection console is used to collect fault injection configuration information and send the fault injection configuration information to the virtualized software and hardware platform.
- the fault injection configuration information is used to indicate fault injection points and fault types, so The fault injection point is located in the virtualized hardware module or the embedded software module;
- the virtualization software and hardware platform is configured to receive the fault injection configuration information and perform fault injection to the fault injection point according to the fault type.
- the test system further includes: a controlled object simulation platform;
- the virtualized software and hardware platform is also used to generate a control signal after fault injection, and send the control signal to the controlled object simulation platform;
- the controlled object simulation platform is used to perform performance simulation on the controlled object according to the control signal to obtain fault test feedback results.
- the controlled object simulation platform is also used to send the fault test feedback results to the virtualization software and hardware platform;
- the virtualization software and hardware platform is also used to send the fault test feedback results to the fault injection console;
- the fault injection console is also used to perform fault analysis based on the fault test feedback results and preconfigured expected fault processing results.
- the fault injection console includes a fault configuration module and a fault recovery module;
- the fault configuration module is used to provide a human-computer interaction interface and collect the fault injection configuration information through the human-computer interaction interface;
- the fault recovery module is configured to receive the fault test feedback result, and perform fault analysis based on the fault test feedback result and the preconfigured expected fault processing result.
- the virtualized software and hardware platform further includes a hardware fault injection module and a software fault injection module.
- the hardware fault injection module is configured to inject hardware faults into the fault injection point located in the virtualized hardware module according to the fault type;
- the software fault injection module is configured to inject software faults into the fault injection point located in the embedded software module according to the fault type.
- the virtualization software and hardware platform and The controlled object simulation platform is deployed on a cloud server.
- the virtualization software and hardware platform and the controlled object simulation platform are provided with a unified The simulation clock or hardware clock is configured, and the virtualization software and hardware platform and the controlled object simulation platform perform step synchronization settings through code injection or state injection.
- inventions of the present application provide a testing device, which is applied to a virtualization software and hardware platform.
- the virtualization software and hardware platform includes a virtualization hardware module and an embedded software module, wherein the virtualization software and hardware platform includes a virtualization hardware module and an embedded software module.
- the virtualized hardware module is used to represent a virtualized embedded hardware system that can run on a general-purpose computer.
- the device includes:
- Obtaining module used to obtain fault injection configuration information, the fault injection configuration information is used to indicate the fault injection point and fault type, the fault injection point is located in the virtualized hardware module or the embedded software module;
- An injection module is configured to inject faults into the fault injection points acquired by the acquisition module according to the fault types acquired by the acquisition module.
- the device further includes:
- a translation module is used to dynamically translate the binary execution instructions of the embedded hardware system into binary execution instructions that can be run on a general-purpose computer to obtain the virtualization hardware module.
- the translation module is also used to:
- a target binary execution instruction is determined from the binary execution instructions of the embedded hardware system and the dynamic translation is performed to obtain the virtualized hardware module.
- the device further includes:
- a generation module configured to generate a control signal after performing the fault injection
- the first sending module is used to send the control signal to the controlled object simulation platform, so that the controlled object simulation platform performs performance simulation on the controlled object according to the control signal and obtains fault test feedback results.
- the device further includes:
- a receiving module configured to receive the fault test feedback results
- the second sending module is configured to send the fault feedback result to the fault injection console, so that the fault injection console performs fault analysis based on the fault test feedback result and the preconfigured expected fault processing result.
- the injection module is further configured to: according to the fault type, modify the calibration protocol Alternatively, a hardware fault is injected into the fault injection point located in the virtualized hardware module using a universal measurement and calibration protocol.
- the injection module further Used for: according to the fault type, perform software fault injection into the fault injection point located in the embedded software module through code injection or state injection.
- embodiments of the present application provide a testing device that can perform one or more of the testing methods of the first aspect or multiple possible implementations of the first aspect.
- embodiments of the present application provide a computer program product, including a computer readable code, or a non-volatile computer readable storage medium carrying the computer readable code, when the computer readable code is stored electronically
- the processor in the electronic device executes one or more of the testing methods of the first aspect or multiple possible implementations of the first aspect.
- embodiments of the present application provide a non-volatile computer-readable storage medium on which computer program instructions are stored, and the computer program instructions are used by a processor to execute the above-mentioned first aspect or multiple aspects of the first aspect.
- Figure 1 shows a schematic structural diagram of a test system provided by an embodiment of the present application
- Figure 2 shows an exemplary structural schematic diagram of the virtualization software and hardware platform provided by the embodiment of the present application
- Figure 3 shows an exemplary schematic diagram of the hardware fault injection process provided by the embodiment of the present application
- Figure 4 shows an interactive flow chart of the testing method provided by the embodiment of the present application
- Figure 5 shows an exemplary structural schematic diagram of a test system provided by an embodiment of the present application
- Figure 6 shows a schematic structural diagram of a testing device provided by an embodiment of the present application.
- FIG. 7 shows a schematic structural diagram of an electronic device provided by an embodiment of the present application.
- exemplary means "serving as an example, example, or illustrative.” Any embodiment described herein as “exemplary” is not necessarily to be construed as superior or superior to other embodiments.
- Software-based fault injection is to inject faults at the software level to generate errors, thereby creating hardware or system-level faults, and then analyze the system feedback data after the fault is injected to conduct system reliability testing.
- the fault injection point is in the software system, such as in the application programming interface (Application Programming Interface, API) of the application software, or in the API of the operating system (Operating System, OS), etc.
- fault injection methods can include directly modifying the statements of the executing program, modifying or adding or deleting data in the software system, modifying the running status of the software system, or modifying memory data through software debugging tools. After flexibly selecting fault injection points and fault injection methods, software modules such as application software, operating systems, and underlying driver software can be tested.
- the above-mentioned software fault injection method has the characteristics of low cost and easy control. It does not require additional hardware equipment. Flexible fault injection points and multiple fault injection methods can be selected at the entire software level. It is widely used in software system testing. The above software-based fault injection has the problem that it can only test software faults but cannot test hardware faults.
- Hardware-based fault injection is to incorporate the hardware system into the test system, and at the same time select the fault injection point for the hardware and select the corresponding fault injection method.
- Embedded systems generally include hardware components such as computing, storage, communication, input and output (Input Output, IO). These hardware components themselves or their interfaces can be used as fault injection points.
- the fault injection method can be that the hardware component itself fails or The hardware interface pin has failed.
- System reliability testing is performed by introducing faults on hardware components and then analyzing the system feedback data after the fault is injected.
- the above hardware-based fault injection method requires the construction of a hardware system for each fault test system. It can be seen that if a large number of hardware fault injection tests are performed, a large number of hardware devices need to be configured, which results in high testing costs and low testing efficiency. In addition, in chip packaging, system-on-chip and other scenarios, many hardware components are packaged together, and the hardware fault injection location is inaccessible, resulting in the problem of incomplete fault injection testing, that is, the problem of low hardware fault test coverage.
- the embodiments of this application provide a testing method, system and device, which can be applied to the testing and verification of any electronic control system that combines software and hardware, including automotive electronic control systems, robot electronic control systems, etc.
- a virtualized embedded hardware system that can run on a general-purpose computer is used to replace the actual hardware device, thereby reducing the testing cost; fault injection into the virtualized embedded hardware system is just like software fault injection. Injection is equally flexible, thereby improving hardware fault test coverage.
- the virtualized embedded hardware system and the controlled object simulation platform are all deployed in the cloud, thereby improving the testing efficiency and the utilization rate of the testing system.
- Figure 1 shows a schematic structural diagram of a test system provided by an embodiment of the present application.
- the test system provided by the embodiment of the present application includes a fault injection console, a virtualization software and hardware platform, and a controlled object simulation platform.
- the fault injection console is the entrance to the test system for testers to operate. After testers log in to the fault injection console, they can initiate fault injection tests.
- the virtualized software and hardware platform can perform software and hardware fault injection after the fault injection test initiated by the tester.
- the controlled object simulation platform can virtualize the software and hardware platform and initiate simulation test verification after completing fault injection.
- testers can log in to the fault injection console through the terminal device.
- the virtualization hardware platform and the controlled object simulation platform can be deployed on the cloud server, and they can be deployed on the same cloud server or on different cloud servers. This is not limited by the embodiments of this application.
- the terminal device and the cloud server can communicate. The embodiments of this application do not limit the communication method between the terminal device and the cloud server. The specific information of each part that constitutes the test system is described in detail below.
- the fault injection console is the entrance to the test system for testers to operate.
- the form of fault injection console includes but is not limited to applications, applets, or web pages.
- the front-end of the fault injection console provides a human-computer interaction interface for interacting with testers, and the back-end provides functions for interacting with virtualized software and hardware platforms.
- the fault injection configuration information selected by the tester is transmitted to the virtualization software and hardware platform; on the other hand, the fault test feedback results are received from the virtualization software and hardware platform. Therefore, the terminal device used by testers to log in to the fault injection console only needs to be able to provide a human-computer interaction interface and back-end communication functions.
- the terminal device involved in the embodiments of this application may be a smartphone, a netbook, a tablet, a notebook, a wearable electronic device (such as a smart bracelet, a smart watch, etc.), a TV, a virtual reality device, etc.
- the embodiments of this application are not limiting.
- the fault injection console can be used to collect fault injection configuration information and send the fault injection configuration information to the virtualization hardware platform.
- the fault injection configuration information can be used to indicate the fault injection point and fault type.
- the fault injection point can be used to indicate the location of the injected fault.
- the fault injection point may be located in the virtualized hardware module or the embedded software module.
- the virtualized hardware module and the embedded software module will be introduced later and will not be detailed here. .
- When the fault injection point is located in the virtualized hardware module it indicates that the fault to be injected is a hardware fault; when the fault injection point is located in the embedded software module, it indicates that the fault to be injected is a software fault.
- the fault type can be used to indicate the type of injected fault. Different fault types require different injection methods for fault injection. Fault injection points, fault types and fault injection methods will be introduced later and will not be described in detail here.
- the fault injection console includes a fault configuration module and a fault recovery module.
- the fault configuration module can be used to provide a human-computer interaction interface, and collect fault injection configuration information through the human-computer interaction interface.
- the fault recovery module may be configured to receive the fault test feedback result, and perform fault analysis based on the fault test feedback result and the preconfigured expected fault processing result.
- the fault test feedback results come from the virtualization software and hardware platform. For fault analysis methods, you can refer to related technologies and will not be repeated here.
- the tester can select the fault injection point and fault type through the fault injection console; at the same time, the expected fault processing results need to be configured to match the actual fault test results (that is, fault tests from the virtualized software and hardware platform feedback results) for comparison.
- the embodiment of this application provides a fault mode library based on existing experience (the fault mode library stores multiple fault injection points and multiple fault types) for testers to choose. Of course, testers can also manually Configure fault injection points and fault types.
- the virtualization software and hardware platform may be configured to receive the fault injection configuration information and perform fault injection to the fault injection point according to the fault type.
- FIG. 2 shows an exemplary structural diagram of a virtualization software and hardware platform provided by an embodiment of the present application.
- the virtualization software and hardware platform includes virtualization hardware modules and embedded software modules.
- the virtualization hardware module may be used to represent a virtualized embedded hardware system that can run on a general-purpose computer.
- virtualized hardware modules include but are not limited to virtualized central processing unit (CPU), virtualized memory, virtualized bus, virtualized onboard communication module, virtualized IO module, etc.
- hardware virtualization can be divided into different types such as full virtualization, partial virtualization, and operating system virtualization according to different virtualization levels. The specific type can be flexibly determined according to the testing requirements of the actual system. selection, thereby improving the efficiency of virtualized hardware module runtime.
- the binary execution instructions of the embedded hardware system can be dynamically translated into binary execution instructions that can be run on a general-purpose computer to obtain the virtualized hardware module.
- the entire embedded hardware system can be virtualized, and then the embedded hardware system can be simulated and run on a general-purpose computer.
- the virtualization of the embedded hardware system can be refined to the granularity of the instruction set. This provides a guarantee for the simulation accuracy of the hardware.
- the dedicated instruction set of the embedded hardware system can be dynamically translated into a general x86 instruction set, and a virtual hardware embedded system can be simulated on a general-purpose computer.
- dynamically translating the binary execution instructions of the embedded hardware system into binary execution instructions that can be run on a general-purpose computer, and obtaining the virtualized hardware module may include: according to the test requirements, from the embedded The target binary execution instruction is determined among the binary execution instructions of the conventional hardware system and the dynamic translation is performed to obtain the virtualization hardware module.
- the target binary execution instruction represents any part of the binary execution instructions in the binary execution instructions of the embedded hardware system. It can be seen that in the embodiment of the present application, part of the embedded hardware system can be virtualized, and then part of the embedded hardware system can be simulated and run on a general-purpose computer.
- the operating system of the embedded hardware system can also be virtualized, and then the operating system of the embedded hardware system can be simulated on a general-purpose computer.
- the virtualized Electronic Control Unit (ECU) resource cloud is used as the virtualized software and hardware platform, which requires the microcontroller unit (Micro Controller Unit, MCU) and the main processing unit (Master Process Unit). , MPU), memory, IO and communication modules are virtualized to obtain the above virtualization software and hardware platform.
- MCU Micro Controller Unit
- Master Process Unit Master Process Unit
- a fully virtualized MCU is a complete independent operating system that can run the same operating system as the actual hardware MCU, so the actual generated code can run directly on the fully virtualized MCU.
- open source software such as Quick EMUlator (QEMU) can be used to achieve full virtualization of the MCU.
- system design based on the C++ language
- QEMU computer language for system design
- microarchitecture simulator microarchitecture simulator, macsim
- EMUlator EMU
- MPU For MPU systems, because the hardware of the MPU is similar to that of a general-purpose computer, and the main frequency of the MPU is higher, the computing pressure of a fully virtualized MPU is greater for a general-purpose computer. Therefore, partial virtualization can be used to virtualize the MPU or Only the operating system of the MPU is virtualized.
- technologies such as OpenVZ, Linux Virtual Server (Linux VServer), Linux Containers (LXC), etc. may be used to implement MPU virtualization.
- Embedded software modules may be used to represent actual software capable of running on virtualized embedded hardware systems.
- embedded software modules include but are not limited to software modules such as basic software, operating systems, and application software. These software modules are real software codes used for actual generation.
- the real embedded software module and the high-precision virtualized hardware module provide the basis for constructing a complete high-precision fault injection test.
- the virtualized software and hardware platform also includes a hardware fault injection module and a software fault injection module.
- the hardware fault injection module can be used to inject hardware faults into the fault injection point located in the virtualized hardware module according to the fault type
- the software fault injection module can be used to inject hardware faults into the fault injection point located in the embedded software according to the fault type.
- the fault injection point of the module performs software fault injection.
- software faults can be divided into: functional faults, algorithm faults, sequence faults, inspection faults and assignment faults; according to function and operating environment, software faults can be divided into: external interface Types of faults, interaction faults between internal modules, configuration faults, data faults, resource faults, operating system faults, and driver faults. It can be seen that software faults involve many levels and types, and the fault coverage rate is high.
- software fault injection can be performed through code injection.
- Code injection is to directly change a certain part of the original code to produce a syntactically correct but semantically incorrect fault point.
- By applying a patch to a specific location in the target code the behavior of the code under test is changed, thereby achieving the goal of software fault injection. Purpose.
- software fault injection can be performed through state injection.
- State injection is to inject faults by changing the running status or behavior of the software system, and by simulating the errors caused by a fault, test the final response of the entire system. For example, to test the system's fault tolerance for data inconsistencies, you can deliberately modify the data type, and then observe the difference between the subsequent output results of the system and the output results of normal operation.
- software fault injection can be achieved through the following technical means.
- the first is software fault injection based on piling: piling is performed in the software module to force the software to run and test the fault mode set by the user instead of the normal mode, thereby achieving fault injection.
- the second type is process-based soft fault injection: In the software fault injection module, a high-priority process dedicated to fault injection is initiated. This process can modify the calculation status to achieve fault injection.
- the third type is debugger-based soft fault injection: using the tools provided by the debugger to inject errors into a running process by setting breakpoints.
- the tools provided by the debugger can be debugger (debugger, dbx) or gun debugger (gun debugger, gdb), etc.
- message-based software fault injection For software modules that communicate through messages, message-based tools can be used to deliberately destroy the content and sequence of messages to generate wrong messages, thereby achieving software fault injection.
- the fifth type is storage-based software fault injection: using memory operation tools to directly modify the data and status values of software modules in the memory, inject faults into the storage system, and introduce faults through the storage system.
- the sixth type is command-based software fault injection: using commands from the tester interface or remote maintenance port to change the status of the system such as running, operation, management, operation and maintenance, etc., so that it works in the fault mode, that is, to inject faults into the test software in the system.
- MCU failure causes the code to not run normally
- memory failure causes data loss or inability to read and write
- IO failure causes the inability to connect to external devices.
- the communication link fails, resulting in the inability to send and receive data normally, etc.
- this can be achieved by modifying the calibration protocol (CAN Calibration Protocol, CCP) or the Universal Measurement and Calibration Protocol (Universal Measurement and Calibration Protocol, XCP).
- CCP is a matching calibration protocol based on the Controller Area Network bus (Controller Area Network, CAN) bus, which can detect or modify the variable values inside the ECU online.
- CANape is a CCP-based ECU calibration and testing tool.
- the communication between CANape and ECU is realized through a description file, which records the detailed information of each parameter in the ECU, such as the storage address, storage structure, data type and conversion formula of variables in the ECU, etc. Through this file, you can directly access and modify the variables in the ECU.
- the specific modification process is realized through the mapping mechanism specified by the CCP protocol, which ensures that the content in the description file and the actual variables inside the ECU are synchronized.
- the XCP protocol is an extension of the CCP protocol. It can adapt to a variety of underlying network protocols and bus types, such as CAN, Ethernet, FlexRay, Serial Communication Interface (SCI), Serial Peripheral Interface ( Serial Peripheral Interface (SPI), Universal Serial Bus (Universal Serial Bus, USB), etc
- FIG 3 shows an exemplary schematic diagram of the hardware fault injection process provided by the embodiment of the present application.
- the hardware fault injection module and the virtualization hardware module are connected through a virtual bus.
- the hardware fault injection module adds fault injection points to the description file of the CCP protocol or XCP protocol, and maps these fault injection points to the registers of various hardware modules such as CPU, memory, IO or communication through the CCP protocol or XCP protocol.
- the hardware fault injection module modifies the variables in the description file. By modifying these variables and injecting the required various fault status and data (i.e., fault types), these variables will be automatically mapped to the virtualized hardware module, thus achieving Hardware fault injection.
- the original function of the CCP protocol and the XCP protocol is to calibrate and match the internal variables of the ECU.
- the mapping relationship between the description files in the CCP protocol and the XCP protocol to the ECU memory address space is used to inject faults.
- the software fault injection module is similar to the software-based fault injection method in related technologies, while the flexibility of the hardware fault injection module is greatly increased, because after hardware virtualization, fault injection into hardware is like software Fault injection is equally flexible, thereby greatly improving the coverage and efficiency of hardware fault injection testing.
- virtualized hardware modules can be replicated on a large scale, which greatly reduces costs compared with large-scale deployment of actual embedded hardware systems.
- the fault injection technology of virtualized hardware is cleverly designed by using the mapping relationship between the description file in the CCP protocol or XCP protocol and the ECU memory address space.
- the software can directly use the actual production code, which is more accurate than pure software in the loop (Software In Loop, SIL) simulation verification.
- the virtualized software and hardware platform can also be used to generate control signals after fault injection, and send the control signals to the controlled object simulation platform.
- the function of the controlled object simulation platform is to replace the actual controlled object with high-precision simulation method.
- the vehicle simulation tool cloud can be used to replace the actual vehicle.
- the controlled object simulation platform can be used to: receive control information from the virtualized software and hardware platform; perform performance simulation of the accused crime according to the control signal to obtain fault test feedback results; and send fault test feedback results to the virtualization Software and hardware platforms. Afterwards, after the virtualization software and hardware platform receives the fault test feedback results, it can send the fault test feedback results to the fault recovery module of the fault injection console for analysis.
- vehicle simulation tools mainly include dynamics simulation tools and economic simulation tools. Therefore, the performance simulation performed in the controlled object simulation platform mainly includes dynamics simulation and economic simulation. Among them, the dynamics simulation mainly simulates the vehicle's acceleration ability, climbing ability, etc., and the economic simulation mainly simulates the vehicle's endurance ability, etc.
- existing commercial or open source vehicle simulation tools can be directly deployed in the cloud, and then directly connected to the virtualized ECU resource cloud (corresponding to the controlled object simulation platform shown in Figure 1) Virtualization software and hardware platform) can be connected.
- the virtualized software and hardware platform and the controlled object simulation platform can achieve synchronization by setting a unified simulation clock or configuring a hardware clock, and achieve step synchronization setting through code injection or state injection. Therefore, after deploying the vehicle simulation tool and the virtualized ECU resource cloud in the cloud, you can synchronize the vehicle simulation tool and the virtualized ECU resource cloud by setting a unified simulation clock or configuring a hardware clock.
- the method of configuring the hardware clock can refer to the method of hardware fault injection, which will not be described again here.
- the setting method of synchronization step size can refer to the software fault injection method, which will not be described again here.
- fault injection testing is to observe the deviation between the response of the system after fault injection and the response of the normally working system, thereby evaluating the reliability of the system. Therefore, the accuracy and timeliness of fault feedback play an important role in the test system.
- fault feedback is the output data or status of the software system, which is generally recorded in the form of logs and then analyzed offline.
- the hardware-based test system either the log method is used to record the fault in the hardware system and then exported for offline analysis; or the hardware system is connected to the actual controlled system and the feedback data of the controlled system is collected to analyze the fault. analyze.
- the fault feedback recording method described above shows that by recording logs and analyzing data offline, it is equivalent to the entire fault testing system being an open-loop system.
- the tested software and hardware system is not connected to the actual controlled object, and lacks Real feedback of software and hardware failures from actual controlled objects.
- the simulation system of the controlled object is used to replace the actual controlled object.
- a complete closed-loop system of fault injection, control, simulation, and test result feedback is realized, so that the actual controlled system can be obtained.
- Real feedback in the event of software and hardware failures improves the accuracy of fault test feedback results; on the other hand, it further reduces testing costs.
- Figure 4 shows an interactive flow chart of the testing method provided by the embodiment of the present application. This method can be applied to the test system shown in Figure 1. As shown in Figure 4, the method includes:
- Step S400 The tester configures the fault injection configuration information on the fault injection console.
- the fault injection configuration information can be used to indicate the fault injection point and fault type.
- the fault injection point can be used to indicate the location of the injected fault.
- the fault injection point may be located in a virtualized hardware module or an embedded software module.
- a virtualized hardware module may be used to represent a virtualized embedded hardware system capable of running on a general-purpose computer.
- virtualized hardware modules include but are not limited to virtualized central processing unit (CPU), virtualized memory, virtualized bus, virtualized onboard communication module, virtualized IO module, etc.
- Embedded software modules may be used to represent actual software capable of running on virtualized embedded hardware systems.
- embedded software modules include but are not limited to software modules such as basic software, operating systems, and application software. These software modules are real software codes used for actual generation.
- a fault mode library (which stores multiple fault injection points and multiple fault types) is provided based on existing experience for testers to choose. Of course, testers can also manually configure fault injection points and faults. type.
- Step S401 The fault injection console collects fault injection configuration information.
- Step S402 The fault injection console sends the fault injection configuration information to the virtualization software and hardware platform.
- Step S403 The virtualization software and hardware platform performs fault injection to the fault injection point indicated by the fault injection configuration information according to the fault type indicated by the fault injection configuration information.
- the virtualized software and hardware platform can inject hardware faults to the fault injection point located in the virtualized hardware module through a hardware fault injection module; and inject software faults into the fault injection point located in the embedded software module through a software fault injection module. .
- the injection methods of software faults and hardware faults are as mentioned above and will not be described again here.
- Step S404 After performing fault injection, the virtualization software and hardware platform generates a control signal.
- the control signal can be used to control the controlled object simulation platform to run the controlled object.
- the control signal may be vehicle simulation control information, and the vehicle simulation control information may be used to control the operation of the vehicle simulated in the vehicle simulation tool cloud.
- Step S405 The virtualization software and hardware platform sends the control signal to the controlled object simulation platform.
- Step S406 The controlled object simulation platform performs performance simulation on the controlled object according to the control signal, and obtains fault test feedback results.
- Step S407 The controlled object simulation platform sends the fault test feedback results to the virtualization software and hardware platform.
- Step S408 The virtualization software and hardware platform sends the controlled object simulation platform to the fault injection console.
- Step S409 The fault injection console performs fault analysis based on the fault test feedback results and the preconfigured expected fault processing results.
- a virtualized embedded hardware system that can run on a general-purpose computer is used to replace the actual hardware device, thereby reducing the testing cost; fault injection into the virtualized embedded hardware system is just like software fault injection. Injection is equally flexible, thereby improving hardware fault test coverage.
- the virtualized embedded hardware system and the controlled object simulation platform are all deployed in the cloud, thereby improving the testing efficiency and the utilization rate of the testing system.
- Figure 5 shows an exemplary structural schematic diagram of a test system provided by an embodiment of the present application.
- the system includes a fault injection console, a virtualized ECU resource cloud and a vehicle simulation tool cloud.
- the fault injection console can refer to the fault injection console shown in Figure 1
- the virtualized ECU resource cloud can refer to the virtualized software and hardware platform shown in Figure 1
- the vehicle simulation tool cloud can refer to the controlled object shown in Figure 1
- the simulation platform will not be described in detail here.
- the implementation method is as follows:
- the tester selects the injection point located in the virtual hardware module through the fault injection console.
- the fault injection point is the variable torque located on the random access memory (Random Access Memory, RAM) in ECU1.
- the tester can select ECU1, RAM, variable and torque in sequence on the human-computer interaction interface, and then modify the value of the variable torque to the fault injection value that needs to be tested. It is assumed here that it is modified to 0.
- the virtualized ECU resource cloud performs fault input.
- the above fault injection can be implemented by using the ECU memory read and write function of the CCP protocol. It should be noted that what is modified here is not the memory data of the physical ECU, but the memory data of the virtual ECU. The specific process is as follows:
- Step 1 The fault injection console writes the fault injection configuration information configured by the tester into the CRO (command receiving object) message of the CCP protocol.
- the first byte of the CRO message is the Command Prompt (CMD), which is used to describe the purpose of the message; the second byte of the CRO message is the command counter (CTR), which is used to track and record communications; CRO
- CMD Command Prompt
- CTR command counter
- CRO third to eighth bytes of the message are used to store specific modified data and its address in memory.
- the fault injection console needs to write the address and value of the variable torque in the ECU memory into the CRO message.
- the specific writing method please refer to the CCP protocol, which will not be described here.
- Step 2 The fault injection console sends the CRO message to the CCP driver module of the virtualized ECU resource cloud through the local CCP driver module. This step is achieved through the virtual CAN bus function provided by the CCP protocol.
- Step 3 After receiving the CRO message, the CCP module of the virtualized ECU resource cloud parses the commands and parameters in it, and then executes the memory modification instruction, that is, it finds the specified memory address and modifies the content to 0. After completing the modification, the virtualized ECU resource cloud feeds back the modification results to the fault injection console through DTO (data transfer object) messages.
- DTO data transfer object
- the vehicle simulation tool cloud performs fault testing.
- testers can initiate simulation test verification.
- the virtual ECU resource cloud begins to execute the test cases issued by the tester.
- the torque variable in the virtual ECU resource cloud memory was modified to 0 by the fault injection function.
- the test case initiates a steering command in the driver model at this time, because the torque variable in the memory is injected with 0, which is equivalent to not detecting the driver's input torque, and the steering control algorithm will not output the steering assist control signal. Therefore, the corresponding steering action will not occur as expected in the vehicle simulation tool cloud, resulting in a malfunction.
- the vehicle simulation tool cloud can generate fault test feedback results and send the fault test feedback results to the virtualized ECU resource cloud.
- the virtualized ECU resource cloud sends the received fault test feedback results to the fault injection console.
- the fault injection console can perform fault analysis based on fault test feedback results and pre-configured expected fault processing results.
- test system after the entire test system is deployed in the cloud, it is equivalent to forming a set of virtualized test benches on the cloud. Because this system is a pure software system and does not require any hardware equipment, it can be replicated on a large scale on the deployed cloud platform, so that it can test multiple test cases at the same time, or provide it to many tests in a multi-user manner. Personnel use at the same time.
- test cases there are 10,000 test cases in the test verification of the vehicle control system. If all these test cases have to be completed through a hardware test bench, the bench cost and time cost will be very high. In fact, most test cases (80% or more) do not have to be completed on the hardware test bench, and can be completed on the virtualization test bench proposed in the embodiment of this application. At this time, only the remaining test cases can be completed. 2,000 test cases with mandatory requirements must pass the hardware test bench and be tested on the hardware test bench. In this way, on the one hand, the pressure on the hardware test bench is reduced, and on the other hand, large-scale parallel testing of 8,000 test cases is performed on the virtualized test bench. The test can be completed in a short time, improving efficiency. .
- Figure 6 shows a schematic structural diagram of a testing device provided by an embodiment of the present application.
- the device 600 can be applied to the virtualization software and hardware platform shown in Figure 1. As shown in Figure 6, the device 600 may include:
- Obtaining module 601 is used to obtain fault injection configuration information.
- the fault injection configuration information is used to indicate a fault injection point and a fault type.
- the fault injection point is located in the virtualized hardware module or the embedded software module;
- the injection module 602 is configured to inject faults into the fault injection points acquired by the acquisition module 601 according to the fault types acquired by the acquisition module 601 .
- the device further includes:
- a translation module is used to dynamically translate the binary execution instructions of the embedded hardware system into binary execution instructions that can be run on a general-purpose computer to obtain the virtualization hardware module.
- the translation module is also used to:
- a target binary execution instruction is determined from the binary execution instructions of the embedded hardware system and the dynamic translation is performed to obtain the virtualized hardware module.
- the device further includes:
- a generation module configured to generate a control signal after performing the fault injection
- the first sending module is used to send the control signal to the controlled object simulation platform, so that the controlled object simulation platform performs performance simulation on the controlled object according to the control signal and obtains fault test feedback results.
- the device further includes:
- a receiving module configured to receive the fault test feedback results
- the second sending module is configured to send the fault feedback result to the fault injection console, so that the fault injection console performs fault analysis based on the fault test feedback result and the preconfigured expected fault processing result.
- the injection module is also configured to: according to the fault type, perform hardware fault injection to the fault injection point located in the virtualized hardware module by modifying the calibration protocol or the universal measurement and calibration protocol. injection.
- the injection module is further configured to inject software faults into the fault injection point located in the embedded software module by means of code injection or state injection according to the fault type.
- a virtualized embedded hardware system that can run on a general-purpose computer is used to replace the actual hardware device, thereby reducing the testing cost; fault injection into the virtualized embedded hardware system is just like software fault injection. Injection is equally flexible, thereby improving hardware fault test coverage.
- the virtualized embedded hardware system and the controlled object simulation platform are all deployed in the cloud, thereby improving the testing efficiency and the utilization rate of the testing system.
- FIG. 7 shows a schematic structural diagram of an electronic device provided by an embodiment of the present application.
- the electronic device can be used as a terminal device or a cloud server, and the electronic device can be used to deploy the fault injection console, virtualization software and hardware platform or controlled object simulation platform shown in Figure 1.
- the computing device may include at least one processor 301 , a memory 302 , an input-output device 303 and a bus 304 .
- processor 301 the computing device may include at least one processor 301 , a memory 302 , an input-output device 303 and a bus 304 .
- memory 302 the computing device may include at least one processor 301 , a memory 302 , an input-output device 303 and a bus 304 .
- the processor 301 is the control center of the computing device, and may be a processor or a collective name for multiple processing elements.
- the processor 301 is a CPU, or it can be an Application Specific Integrated Circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present application, such as one or more microprocessors.
- ASIC Application Specific Integrated Circuit
- DSP Digital Signal Processor
- FPGA Field Programmable Gate Array
- the processor 301 can perform various functions of the computing device by running or executing software programs stored in the memory 302 and calling data stored in the memory 302.
- the processor 301 may include one or more CPUs, such as CPU 0 and CPU 1 shown in the figure.
- the computing device may include multiple processors, such as the processor 301 and the processor 305 shown in FIG. 7 .
- processors can be a single-core processor (single-CPU) or a multi-core processor (multi-CPU).
- a processor here may refer to one or more devices, circuits, and/or processing cores for processing data (eg, computer program instructions).
- the memory 302 may be a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (Random Access Memory, RAM) or other types that can store information and instructions.
- ROM read-only memory
- RAM Random Access Memory
- dynamic storage device which may also be an electrically erasable programmable read-only memory
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Test And Diagnosis Of Digital Computers (AREA)
Abstract
Description
Claims (23)
- 一种测试方法,其特征在于,所述方法应用于虚拟化软硬件平台,所述虚拟化软硬件平台包括虚拟化硬件模块和嵌入式软件模块,其中,所述虚拟化硬件模块用于表示能够在通用计算机上运行的虚拟化的嵌入式硬件***,所述方法包括:获取故障注入配置信息,所述故障注入配置信息用于指示故障注入点和故障类型,所述故障注入点位于所述虚拟化硬件模块或者所述嵌入式软件模块;根据所述故障类型向所述故障注入点进行故障注入。
- 根据权利要求1所述的方法,其特征在于,所述方法还包括:将嵌入式硬件***的二进制执行指令动态翻译为能够在通用计算机上运行的二进制执行指令,得到所述虚拟化硬件模块。
- 根据权利要求2所述的方法,其特征在于,所述将嵌入式硬件***的二进制执行指令动态翻译为能够在通用计算机上运行的二进制执行指令,得到所述虚拟化硬件模块,包括:根据测试需求,从所述嵌入式硬件***的二进制执行指令中确定目标二进制执行指令进行所述动态翻译,得到所述虚拟化硬件模块。
- 根据权利要求1至3中任意一项所述的方法,其特征在于,所述方法还包括:在进行所述故障注入后,生成控制信号;将所述控制信号发送至被控对象仿真平台,以使所述被控对象仿真平台按照所述控制信号对被控对象进行性能仿真,得到故障测试反馈结果。
- 根据权利要求4所述的方法,其特征在于,所述方法还包括:接收所述故障测试反馈结果;将所述故障反馈结果发送至故障注入控制台,以使所述故障注入控制台根据所述故障测试反馈结果与预先配置的期望故障处理结果,进行故障分析。
- 根据权利要求1至5中任意一项所述的方法,其特征在于,所述根据所述故障类型向所述故障注入点进行故障注入,包括:根据所述故障类型,通过改造标定协议或者通用测量与标定协议的方式向位于所述虚拟化硬件模块的故障注入点进行硬件故障注入。
- 根据权利要求1至5中任意一项所述的方法,其特征在于,所述根据所述故障类型向所述故障注入点进行故障注入,包括:根据所述故障类型,通过代码注入或者状态注入的方式向位于所述嵌入式软件模块的故障注入点进行软件故障注入。
- 一种测试***,其特征在于,包括:故障注入控制台和虚拟化软硬件平台,所述虚拟化软硬件平台包括虚拟化硬件模块和嵌入式软件模块,其中,所述虚拟化硬件模块用于表示能够在通用计算机上运行的虚拟化的嵌入式硬件***;所述故障注入控制台,用于采集故障注入配置信息,并将所述故障注入配置信息发送至所述虚拟化软硬件平台,所述故障注入配置信息用于指示故障注入点和故障类型,所述故障注入点位于所述虚拟化硬件模块或者所述嵌入式软件模块;所述虚拟化软硬件平台,用于接收所述故障注入配置信息,并按照所述故障类型向所述故障注入点进行故障注入。
- 根据权利要求8所述的***,其特征在于,所述测试***还包括:被控对象仿真平台;所述虚拟化软硬件平台,还用于在进行故障注入后,生成控制信号,并将所述控制信号发送至所述被控对象仿真平台;所述被控对象仿真平台,用于按照所述控制信号对被控对象进行性能仿真,得到故障测试反馈结果。
- 根据权利要求9所述的***,其特征在于,所述被控对象仿真平台,还用于将所述故障测试反馈结果发送至所述虚拟化软硬件平台;所述虚拟化软硬件平台,还用于将所述故障测试反馈结果发送至所述故障注入控制台;所述故障注入控制台,还用于根据所述故障测试反馈结果与预先配置的期望故障处理结果,进行故障分析。
- 根据权利要求8或10所述的***,其特征在于,所述故障注入控制台包括故障配置模块和故障回收模块;所述故障配置模块,用于提供人机交互界面,并通过所述人机交互界面采集所述故障注入配置信息;所述故障回收模块,用于接收所述故障测试反馈结果,并根据所述故障测试反馈结果与预先配置的期望故障处理结果,进行故障分析。
- 根据权利要求8至11中任意一项所述的***,其特征在于,所述虚拟化软硬件平台还包括硬件故障注入模块和软件故障注入模块;所述硬件故障注入模块,用于按照所述故障类型向位于所述虚拟化硬件模块的故障注入点进行硬件故障注入;所述软件故障注入模块,用于按照所述故障类型向位于所述嵌入式软件模块的故障注入点进行软件故障注入。
- 根据权利要求9至11中任意一项所述的***,其特征在于,所述虚拟化软硬件平台和所述被控对象仿真平台部署在云服务器上。
- 根据权利要求9至13中任意一项所述的***,其特征在于,所述虚拟化软硬件平台和所述被控对象仿真平台设置有统一的仿真时钟或者配置有硬件时钟,且所述虚拟化软硬件平台和所述被控对象仿真平台通过代码注入或者状态注入的方式进行了步长同步设置。
- 一种测试装置,其特征在于,所述装置应用于虚拟化软硬件平台,所述虚拟化软硬件平台包括虚拟化硬件模块和嵌入式软件模块,其中,所述虚拟化硬件模块用于表示能够在通用计算机上运行的虚拟化的嵌入式硬件***,所述装置包括:获取模块,用于获取故障注入配置信息,所述故障注入配置信息用于指示故障注入点和故障类型,所述故障注入点位于所述虚拟化硬件模块或者所述嵌入式软件模块;注入模块,用于根据所述获取模块获取的故障类型向所述获取模块获取的故障注入点进行故障注入。
- 根据权利要求15所述的装置,其特征在于,所述装置还包括:翻译模块,用于将嵌入式硬件***的二进制执行指令动态翻译为能够在通用计算机上运行的二进制执行指令,得到所述虚拟化硬件模块。
- 根据权利要求16所述的装置,其特征在于,所述翻译模块还用于:根据测试需求,从所述嵌入式硬件***的二进制执行指令中确定目标二进制执行指令进行所述动态翻译,得到所述虚拟化硬件模块。
- 根据权利要求15至17中任意一项所述的装置,其特征在于,所述装置还包括:生成模块,用于在进行所述故障注入后,生成控制信号;第一发送模块,用于将所述控制信号发送至被控对象仿真平台,以使所述被控对象仿真平台按照所述控制信号对被控对象进行性能仿真,得到故障测试反馈结果。
- 根据权利要求18所述的装置,其特征在于,所述装置还包括:接收模块,用于接收所述故障测试反馈结果;第二发送模块,用于将所述故障反馈结果发送至故障注入控制台,以使所述故障注入控制台根据所述故障测试反馈结果与预先配置的期望故障处理结果,进行故障分析。
- 根据权利要求15至19中任意一项所述的装置,其特征在于,所述注入模块还用于:根据所述故障类型,通过改造标定协议或者通用测量与标定协议的方式向位于所述虚拟化硬件模块的故障注入点进行硬件故障注入。
- 根据权利要求15至19中任意一项所述的装置,其特征在于,所述注入模块还用于:根据所述故障类型,通过代码注入或者状态注入的方式向位于所述嵌入式软件模块的故障注入点进行软件故障注入。
- 一种测试装置,其特征在于,包括:处理器;用于存储处理器可执行指令的存储器;其中,所述处理器被配置为执行所述指令时实现权利要求1至7中任意一项所述的方法。
- 一种非易失性计算机可读存储介质,其上存储有计算机程序指令,其特征在于,所述计算机程序指令被处理器执行时实现权利要求1至7中任意一项所述的方法。
(Electrically Erasable Programmable Read-Only Memory,EEPROM)、只读光盘(Compact Disc Read-Only Memory,CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质,但不限于此。存储器302可以是独立存在,通过总线304与处理器301相连接。存储器302也可以和处理器301集成在一起。
输入输出设备303,用于与其他设备或通信网络通信。如用于与以太网,无线接入网(Radio access network,RAN),无线局域网(Wireless Local Area Networks,WLAN)等通信网络通信。输入输出设备303可以包括基带处理器的全部或部分,以及还可选择性地包括无线射频(Radio Frequency,RF)处理器。RF处理器用于收发RF信号,基带处理器则用于实现由RF信号转换的基带信号或即将转换为RF信号的基带信号的处理。
在具体实现中,作为一种实施例,输入输出设备303可以包括发射器和接收器。其中,发射器用于向其他设备或通信网络发送信号,接收器用于接收其他设备或通信网络发送的信号。发射器和接收器可以独立存在,也可以集成在一起。
总线304,可以是工业标准体系结构(Industry Standard Architecture,ISA)总线、外部设备互连(Peripheral Component Interconnect,PCI)总线或扩展工业标准体系结构(Extended Industry Standard Architecture,EISA)总线等。该总线可以分为地址总线、数据总线、控制总线等。为便于表示,图7中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。
图7中示出的设备结构并不构成对计算设备的限定,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件布置。
本申请的实施例提供了一种测试装置,包括:处理器以及用于存储处理器可执行指令的存储器;其中,所述处理器被配置为执行所述指令时实现上述方法。
本申请的实施例提供了一种非易失性计算机可读存储介质,其上存储有计算机程序指令,所述计算机程序指令被处理器执行时实现上述方法。
本申请的实施例提供了一种计算机程序产品,包括计算机可读代码,或者承载有计算机可读代码的非易失性计算机可读存储介质,当所述计算机可读代码在电子设备的处理器中运行时,所述电子设备中的处理器执行上述方法。
计算机可读存储介质可以是可以保持和存储由指令执行设备使用的指令的有形设备。计算机可读存储介质例如可以是(但不限于)电存储设备、磁存储设备、光存储设备、电磁存储设备、半导体存储设备或者上述的任意合适的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括:便携式计算机盘、硬盘、随机存取存储器(Random Access Memory,RAM)、只读存储器(Read Only Memory,ROM)、可擦式可编程只读存储器(Electrically Programmable Read-Only-Memory,EPROM或闪存)、静态随机存取存储器(Static Random-Access Memory,SRAM)、便携式压缩盘只读存储器(Compact Disc Read-Only Memory,CD-ROM)、数字多功能盘(Digital Video Disc,DVD)、记忆棒、软盘、机械编码设备、例如其上存储有指令的打孔卡或凹槽内凸起结构、以及上述的任意合适的组合。
这里所描述的计算机可读程序指令或代码可以从计算机可读存储介质下载到各个计算/处理设备,或者通过网络、例如因特网、局域网、广域网和/或无线网下载到外部计算机或外部存储设备。网络可以包括铜传输电缆、光纤传输、无线传输、路由器、防火墙、交换机、网关计算机和/或边缘服务器。每个计算/处理设备中的网络适配卡或者网络接口从网络接收计算机可读程序指令,并转发该计算机可读程序指令,以供存储在各个计算/处理设备中的计算机可读存储介质中。
用于执行本申请操作的计算机程序指令可以是汇编指令、指令集架构(Instruction Set Architecture,ISA)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数据、或者以一种或多种编程语言的任意组合编写的源代码或目标代码,所述编程语言包括面向对象的编程语言—诸如Smalltalk、C++等,以及常规的过程式编程语言—诸如“C”语言或类似的编程语言。计算机可读程序指令可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中,远程计算机可以通过任意种类的网络—包括局域网(Local Area Network,LAN)或广域网(Wide Area Network,WAN)—连接到用户计算机,或者,可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。在一些实施例中,通过利用计算机可读程序指令的状态信息来个性化定制电子电路,例如可编程逻辑电路、现场可编程门阵列(Field-Programmable Gate Array,FPGA)或可编程逻辑阵列(Programmable Logic Array,PLA),该电子电路可以执行计算机可读程序指令,从而实现本申请的各个方面。
这里参照根据本申请实施例的方法、装置(***)和计算机程序产品的流程图和/或框图描述了本申请的各个方面。应当理解,流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合,都可以由计算机可读程序指令实现。
这些计算机可读程序指令可以提供给通用计算机、专用计算机或其它可编程数据处理装置的处理器,从而生产出一种机器,使得这些指令在通过计算机或其它可编程数据处理装置的处理器执行时,产生了实现流程图和/或框图中的一个或多个方框中规定的功能/动作的装置。也可以把这些计算机可读程序指令存储在计算机可读存储介质中,这些指令使得计算机、可编程数据处理装置和/或其他设备以特定方式工作,从而,存储有指令的计算机可读介质则包括一个制造品,其包括实现流程图和/或框图中的一个或多个方框中规定的功能/动作的各个方面的指令。
也可以把计算机可读程序指令加载到计算机、其它可编程数据处理装置、或其它设备上,使得在计算机、其它可编程数据处理装置或其它设备上执行一系列操作步骤,以产生计算机实现的过程,从而使得在计算机、其它可编程数据处理装置、或其它设备上执行的指令实现流程图和/或框图中的一个或多个方框中规定的功能/动作。
附图中的流程图和框图显示了根据本申请的多个实施例的装置、***、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段或指令的一部分,所述模块、程序段或指令的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个连续的方 框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。
也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行相应的功能或动作的硬件(例如电路或ASIC(Application Specific Integrated Circuit,专用集成电路))来实现,或者可以用硬件和软件的组合,如固件等来实现。
尽管在此结合各实施例对本申请进行了描述,然而,本领域技术人员通过查看所述附图、公开内容、以及所附权利要求书,可理解并实现所述公开实施例的其它变化。在权利要求中,“包括”(comprising)一词不排除其他组成部分或步骤,“一”或“一个”不排除多个的情况。单个处理器或其它单元可以实现权利要求中列举的若干项功能。相互不同的从属权利要求中记载了某些措施,但这并不表示这些措施不能组合起来产生良好的效果。
以上所述,仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应以所述权利要求的保护范围为准。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202280007333.XA CN117597669A (zh) | 2022-05-31 | 2022-05-31 | 一种测试方法、***及装置 |
PCT/CN2022/096367 WO2023230883A1 (zh) | 2022-05-31 | 2022-05-31 | 一种测试方法、***及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/CN2022/096367 WO2023230883A1 (zh) | 2022-05-31 | 2022-05-31 | 一种测试方法、***及装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2023230883A1 true WO2023230883A1 (zh) | 2023-12-07 |
Family
ID=89026646
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2022/096367 WO2023230883A1 (zh) | 2022-05-31 | 2022-05-31 | 一种测试方法、***及装置 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN117597669A (zh) |
WO (1) | WO2023230883A1 (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117724920A (zh) * | 2024-02-07 | 2024-03-19 | 四川赛狄信息技术股份公司 | 一种嵌入式设备的测试方法、装置、上位机及介质 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103529820A (zh) * | 2013-09-26 | 2014-01-22 | 北京航天自动控制研究所 | 一种适用于嵌入式设备的故障注入测试***及测试方法 |
US20170060655A1 (en) * | 2015-08-31 | 2017-03-02 | International Business Machines Corporation | Isolating hardware and network failures in a computing environment |
CN107025171A (zh) * | 2017-03-10 | 2017-08-08 | 深圳航天科技创新研究院 | 一种实现虚拟验证***故障注入的方法 |
CN113127331A (zh) * | 2019-12-31 | 2021-07-16 | 航天信息股份有限公司 | 一种基于故障注入的测试方法、装置及计算机设备 |
CN114063472A (zh) * | 2021-11-18 | 2022-02-18 | 成都邦飞科技有限公司 | 一种数字化仿真设计***、方法、存储介质及电子设备 |
-
2022
- 2022-05-31 CN CN202280007333.XA patent/CN117597669A/zh active Pending
- 2022-05-31 WO PCT/CN2022/096367 patent/WO2023230883A1/zh active Application Filing
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103529820A (zh) * | 2013-09-26 | 2014-01-22 | 北京航天自动控制研究所 | 一种适用于嵌入式设备的故障注入测试***及测试方法 |
US20170060655A1 (en) * | 2015-08-31 | 2017-03-02 | International Business Machines Corporation | Isolating hardware and network failures in a computing environment |
CN107025171A (zh) * | 2017-03-10 | 2017-08-08 | 深圳航天科技创新研究院 | 一种实现虚拟验证***故障注入的方法 |
CN113127331A (zh) * | 2019-12-31 | 2021-07-16 | 航天信息股份有限公司 | 一种基于故障注入的测试方法、装置及计算机设备 |
CN114063472A (zh) * | 2021-11-18 | 2022-02-18 | 成都邦飞科技有限公司 | 一种数字化仿真设计***、方法、存储介质及电子设备 |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117724920A (zh) * | 2024-02-07 | 2024-03-19 | 四川赛狄信息技术股份公司 | 一种嵌入式设备的测试方法、装置、上位机及介质 |
CN117724920B (zh) * | 2024-02-07 | 2024-04-26 | 四川赛狄信息技术股份公司 | 一种嵌入式设备的测试方法、装置、上位机及介质 |
Also Published As
Publication number | Publication date |
---|---|
CN117597669A (zh) | 2024-02-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN103235756B (zh) | 一种面向嵌入式***分区应用程序软件的仿真测试方法 | |
US9465718B2 (en) | Filter generation for load testing managed environments | |
WO2019216976A1 (en) | Analytics for an automated application testing platform | |
US9405315B2 (en) | Delayed execution of program code on multiple processors | |
WO2014088398A1 (en) | Automated test environment deployment with metric recommender for performance testing on iaas cloud | |
CN108628734B (zh) | 一种功能程序调试方法和终端 | |
US7957951B2 (en) | Address translation system for use in a simulation environment | |
CN114528792A (zh) | 芯片验证方法、装置、电子设备及存储介质 | |
WO2024130861A1 (zh) | 一种云原生的硬件逻辑仿真fpga加速方法及*** | |
CN108459951A (zh) | 测试方法和装置 | |
WO2023230883A1 (zh) | 一种测试方法、***及装置 | |
US20130024178A1 (en) | Playback methodology for verification components | |
US20130254750A1 (en) | Method of debugging software and corresponding computer program product | |
CN112860587B (zh) | Ui自动测试方法和装置 | |
CN114548027A (zh) | 在验证***中追踪信号的方法、电子设备及存储介质 | |
CN116467211B (zh) | 一种基于数字化仿真环境的***级测试验证方法 | |
CN117076337A (zh) | 一种数据传输方法、装置、电子设备及可读存储介质 | |
US20070265822A1 (en) | Data processing system and method | |
CN115993937A (zh) | 一种多进程固态硬盘仿真环境实现方法和装置 | |
CN116340150A (zh) | 一种基于uvm的可重用的寄存器性能交互验证***及其应用 | |
US10481969B2 (en) | Configurable system wide tests | |
CN115629928A (zh) | 一种面向类脑处理器的软硬协同验证方法及*** | |
Muli et al. | Virtual validation-a new paradigm in controls engineering | |
CN114756463A (zh) | 一种测试环境开发方法、***、设备以及介质 | |
CA3144852A1 (en) | Automatic generation of integrated test procedures using system test procedures |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
WWE | Wipo information: entry into national phase |
Ref document number: 202280007333.X Country of ref document: CN |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 22944220 Country of ref document: EP Kind code of ref document: A1 |