Parallel fuzzy test device and test method for control system in vehicle-mounted chip

Abstract

The invention discloses a parallel fuzzy test device and test method for a control system in a vehicle-mounted chip, and relates to the technical field of fuzzy test, the parallel fuzzy test device comprises a fuzzy test main controller, a parallel fuzzy test engine, a data transmission module and a vehicle-mounted chip test bench, the fuzzy test main controller comprises a test case scheduler, a system state monitor and a crash analysis and management device, and the test case scheduler comprises a seed queue management unit, a power scheduling unit and a resource allocation unit. Through cooperation of the multiple test case generation modules, the multiple non-intrusive monitoring probes, the multiple multi-axis mechanical arms and the multiple vehicle-mounted chip clamping structures, the multiple vehicle-mounted chips can be clamped, parallel fuzzy detection is carried out on control systems in the multiple vehicle-mounted chips, multi-core computing resources are fully utilized, and the test efficiency is greatly improved.

Description

Technical Field

[0001] This invention relates to the field of fuzzy testing technology, specifically to a parallel fuzzy testing device and method for in-vehicle chip control systems. Background Technology

[0002] Traditional fuzz testing targets application software running on general-purpose operating systems, while in-vehicle chip-based control systems are typically firmware / software running directly on a real-time operating system (RTOS) or bare metal, tightly coupled with hardware (such as CAN bus, sensors, actuators).

[0003] For example, the invention patent with publication number CN117667747A relates to an AUTOSAR-based ECU fuzzing test method and system. The method includes the following steps: S1, generating fuzzy test cases for the AUTOSAR standard using the fuzzing test tool syzkaller and sending them to the ECU for testing; S2, obtaining the ECU's operating status after executing the fuzzy test cases, and parsing it using data analysis technology to obtain dynamic ECU data.

[0004] Taking the aforementioned fuzzy testing device as an example, the interface protocol design of the control system within the vehicle chip is complex. During testing, it is difficult to quickly cover the relevant interfaces, functional paths, and branches. As a result, the fuzzy testing device can only perform overall testing of the control system. It requires a large amount of computing power and time to analyze the specific functions with vulnerabilities, which affects the testing speed of the control system within the vehicle chip. Summary of the Invention

[0005] The purpose of this invention is to provide a parallel fuzzy testing device and method for in-vehicle chip control systems, in order to solve the problems raised in the prior art.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a parallel fuzzy testing device and method for in-vehicle chip control systems, comprising a parallel fuzzy testing device, wherein the parallel fuzzy testing device includes a fuzzy testing main controller, a parallel fuzzy testing engine, a data transmission module, and an in-vehicle chip test bench. The fuzzy testing main controller includes a test case scheduler, a system status monitor, and a crash analysis and manager. The test case scheduler includes a seed queue management unit, a power scheduling unit, and a resource allocation unit. The system status monitor includes a bench data acquisition unit, a system health assessment unit, and a trigger automatic recovery unit. The crash analysis and manager includes a crash deduplication unit, a crash tracing model, and a test report generation unit. The parallel fuzzy testing engine includes multiple test case generation modules, each including a fuzzer instance, a mutant, a protocol syntax, and a generator. The in-vehicle chip test bench includes a non-invasive monitoring probe module, a probe support module, an in-vehicle chip support module, and a touchscreen controller. The non-invasive monitoring probe module includes multiple non-invasive monitoring probes. The in-vehicle chip support module includes multiple in-vehicle chip clamping structures.

[0007] Preferably, the seed queue management unit is used to maintain a high-quality initial seed test case library, and the resource allocation unit dynamically adjusts the mutation strategy of the seed test cases based on the load capacity and monitoring feedback of the control system in the vehicle chip under test.

[0008] Preferably, the benchtop data acquisition unit continuously acquires the status of the control system under test from a non-invasive monitoring probe, and the trigger automatic recovery unit sends instructions to the control touch screen controller when the control system under test freezes or crashes.

[0009] Preferably, the crash tracing model performs in-depth analysis to trace the causes of vulnerabilities in the control system, and the test report generation unit summarizes the analysis results of the crash deduplication unit and the crash tracing model to generate a detailed report of the control system crash.

[0010] Preferably, the protocol syntax is based on the vehicle communication protocol and the chip's internal API specification, and the mutant performs intelligent mutation on the use case seed.

[0011] Preferably, the non-invasive monitoring probe includes a bus monitoring unit and a debug interface monitoring unit.

[0012] Preferably, the vehicle-mounted chip clamping structure includes a clamp, a sealing structure, and a temperature and pressure control structure.

[0013] Preferably, the probe support module includes multiple multi-axis robotic arms, which are used to control the position of the non-invasive monitoring probe.

[0014] Preferably, the touchscreen controller includes a reset control interface, an environment simulation interface, a power control interface, and a power consumption analysis module.

[0015] Preferably, the method includes the following steps: Step 1: Hardware loading, the probe support module and the vehicle chip support module work together to connect the non-invasive monitoring probe to the fixed vehicle chip. Step 2: Initialization: The fuzz test main controller starts working, the touch screen controller starts the vehicle chip under test, and the non-invasive monitoring probe starts working; Step 3: Scheduling and Distribution. The resource allocation unit dynamically adjusts the variation strategy of test cases based on the load capacity of the control system within the vehicle chip and monitoring feedback. Step 4: Mutation and Generation. The mutant mutates a seed use case within the syntactic framework defined by the protocol syntax. Step 5: Execution and Monitoring: The test cases generated in the parallel fuzz testing engine are sent to the vehicle chip under test by the data transmission module in order of priority. Step Six: Feedback and Analysis, Normal Response: The system status monitor does not detect any anomalies. The system status monitor feeds back the fuzzy test results of the test cases to the crash analysis and manager. The test case scheduler adds this test case to the queue for further mutation. Abnormal Response: The system status monitor detects a crash, freeze, or serious anomaly in the control system. Step 7: Cyclic Parallelism. During the fuzzy testing of a test case in the onboard chip control system, if the system status monitor does not detect any anomalies, the test case scheduler marks this test case as a cyclic test case and adds it to the internal queue of the test case scheduler for further mutation. After the mutation strategy is completed, the cyclic test case enters the internal queue of the parallel fuzzy testing engine for deep mutation and is then put back into the fuzzy testing of the control system.

[0016] Compared with the prior art, the beneficial effects of the present invention are: 1. When used in this application, multiple test case generation modules, multiple non-invasive monitoring probes, multiple multi-axis robotic arms, and multiple automotive chip clamping structures work together to clamp multiple automotive chips and perform parallel fuzzy detection on the control systems within these chips. This fully utilizes multi-core computing resources and significantly improves testing efficiency. The resource allocation unit dynamically adjusts the variation strategy of test cases based on the load capacity and monitoring feedback of the control systems within the automotive chips. It considers the hardware characteristics and communication protocol range of the automotive chips, ensuring accurate and efficient data collection during the testing of the control systems within the automotive chips. Non-invasive monitoring probes with high compatibility with the automotive chips are used for data collection, and this non-invasive monitoring ensures that the safety of the control system under test is not affected.

[0017] 2. When this application is used, the parallel fuzzy testing device, through the structural design of the parallel fuzzy testing engine and the vehicle chip test bench, can perform individual tests on different functional units of the control system within a vehicle chip. It simulates the situation where users use multiple functions of the vehicle simultaneously, and after sealing the location of the vehicle chip, it controls the temperature around the vehicle chip to simulate the most common working environment of high-frequency operation of the vehicle chip, ensuring the reference value of the fuzzy test of the control system within the vehicle chip for practical applications. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the parallel fuzzy testing device of the present invention; Figure 2 This is a schematic diagram of the test case scheduler of the present invention; Figure 3 This is a schematic diagram of the system status monitor of the present invention; Figure 4 This is a schematic diagram of the crash analysis and manager of the present invention; Figure 5 This is a schematic diagram of the test case generation module of the present invention; Figure 6 This is a schematic diagram of the vehicle-mounted chip test bench of the present invention; Figure 7 This is a schematic diagram of the vehicle-mounted chip support module of the present invention; Figure 8 This is a schematic diagram of the probe support module of the present invention.

[0019] The diagram is labeled as follows: 1. Parallel fuzzing device; 2. Fuzzing main controller; 21. Test case scheduler; 2101. Seed queue management unit; 2102. Power scheduling unit; 2103. Resource allocation unit; 22. System status monitor; 2201. Bench data acquisition unit; 2202. System health assessment unit; 2203. Triggered automatic recovery unit; 23. Crash analysis and manager; 2301. Crash deduplication unit; 2302. Crash tracing model; 2303. Test report generation unit; 3. Parallel fuzzing engine; 31. Test case generation module; 3101. Fuzzer instance; 31 02. Mutator; 3103. Protocol Syntax; 3104. Generator; 4. Data Transmission Module; 5. Vehicle-Mounted Chip Test Bench; 6. Non-Intrusive Monitoring Probe Module; 61. Non-Intrusive Monitoring Probe; 6101. Bus Listening Unit; 6102. Debug Interface Listening Unit; 7. Probe Support Module; 71. Multi-Axis Robotic Arm; 8. Vehicle-Mounted Chip Support Module; 81. Vehicle-Mounted Chip Clamping Structure; 8101. Fixture; 8102. Sealing Structure; 8103. Temperature and Pressure Control Structure; 9. Touchscreen Controller; 91. Reset Control Interface; 92. Environmental Simulation Interface; 93. Power Control Interface; 94. Power Consumption Analysis Module. Detailed Implementation

[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] Example: Figures 1-8 As shown, this invention provides a parallel fuzzy testing device for in-vehicle chip control systems, including a parallel fuzzy testing device 1. The parallel fuzzy testing device 1 includes a fuzzy testing main controller 2, a parallel fuzzy testing engine 3, a data transmission module 4, and an in-vehicle chip test bench 5. The fuzzy testing main controller 2 includes a test case scheduler 21, a system status monitor 22, and a crash analysis and manager 23. The test case scheduler 21 includes a seed queue management unit 2101, a power scheduling unit 2102, and a resource allocation unit 2103. The system status monitor 22 includes a bench data acquisition unit 2201, a system health assessment unit 2202, and a trigger automatic recovery unit 2203. The crash analysis and manager 23 includes a crash deduplication unit 2301, a crash tracing model 2302, and a test report generation unit 2303. The parallel fuzzy testing engine 3 includes multiple test case generation modules 31. The generation module 31 includes a fuzzer instance 3101, a mutant 3102, a protocol syntax 3103, and a generator 3104. The vehicle-mounted chip test bench 5 includes a non-invasive monitoring probe module 6, a probe support module 7, a vehicle-mounted chip support module 8, and a touch screen controller 9. The non-invasive monitoring probe module 6 includes multiple non-invasive monitoring probes 61, each including a bus listening unit 6101 and a debug interface listening unit 6102. The probe support module 7 includes multiple multi-axis robotic arms 71, which are used to control the position of the non-invasive monitoring probes 61. The vehicle-mounted chip support module 8 includes multiple vehicle-mounted chip clamping structures 81, each including a clamp 8101, a sealing structure 8102, and a temperature and pressure control structure 8103. The touch screen controller 9 includes a reset control interface 91, an environmental simulation interface 92, a power control interface 93, and a power consumption analysis module 94.

[0022] Among them, the fuzz test main controller 2, which consists of test case scheduler 21, system status monitor 22 and crash analysis and manager 23, is responsible for coordinating the work of the parallel fuzz test device 1.

[0023] The test case scheduler 21 detects abnormal functions of the control system under test through the cooperation of the seed queue management unit 2101, the power scheduling unit 2102, and the resource allocation unit 2103. Seed queue management unit 2101 is used to maintain a high-quality initial seed use case library (such as normal CAN messages and diagnostic requests). The power scheduling unit 2102 borrows the "Favored" concept from AFL to allocate more computing resources to seed use cases that can trigger new code paths, that is, to allow more seed use cases to mutate based on it; Resource allocation unit 2103 dynamically adjusts the mutation strategy of seed test cases based on the load capacity and monitoring feedback of the control system in the vehicle chip under test (hereinafter referred to as the control system), namely the number of sub-test cases generated by the mutation of seed test cases and the type of seed test case mutation parameters.

[0024] The system status monitor 22 functions through a benchtop data acquisition unit 2201, a system health assessment unit 2202, and an automatic recovery trigger unit 2203. The benchtop data acquisition unit 2201 continuously acquires the status of the control system under test from the non-intrusive monitoring probe 61, such as abnormal states like CPU load, memory usage, bus error frames, or power consumption. The system health assessment unit 2202 determines whether a reset or test should be performed when the tested control system malfunctions but does not crash (such as memory leaks and task blocking) based on a preset threshold. When the tested control system freezes or crashes, the triggering automatic recovery unit 2203 sends a command to the control touch screen controller 9, and the power control interface 93 in the touch screen controller 9 automatically restarts the tested control system and restores the test environment.

[0025] The crash analysis and manager 23, consisting of a crash deduplication unit 2301, a crash tracing model 2302, and a test report generation unit 2303, is used to analyze the causes of control system crashes and trace the causes of control system vulnerabilities. The crash deduplication unit 2301 performs hash or stack trace analysis on test cases that trigger crashes to avoid duplicate reporting of the same vulnerability. The crash tracing model 2302 obtains the complete context of the crash moment based on records, including test cases, system logs, memory snapshots, power consumption curves and other data, and conducts in-depth analysis to trace the cause of the system vulnerability. The test report generation unit 2303 summarizes the analysis results of the crash deduplication unit 2301 and the crash tracing model 2302 to generate a detailed report on the crash of the control system.

[0026] The parallel fuzz testing engine 3, consisting of multiple test case generation modules 31 running on independent threads or processes, is responsible for generating and sending test cases; The test case generation module 31 for testing the target consists of a fuzzer instance 3101, a mutant 3102, a protocol syntax 3103, and a generator 3104. Fuzzy instance 3101 stores multiple use case seeds; The protocol syntax 3103 is based on vehicle communication protocols (such as CANDBC files, SOME / IPXML descriptions) and chip internal API specifications. It understands the structure of messages (ID, data length, signal meaning) to ensure that the mutation of use case seeds by the mutator 3102 is carried out within a legal syntax framework, which can more effectively explore the deep operating logic of the control system. Mutator 3102 performs intelligent mutation on use case seeds, with strategies including: Bit flipping, flipping each bit with probability p; Arithmetic increment / decrement: Add or subtract values ​​from test case seed values, such as x′=x+δ, where δ is a value randomly selected from a distribution (such as Gaussian distribution). Randomly modify the value of a signal in the CAN message to make it exceed the normal range (such as setting the vehicle speed to 500km / h). Block replacement: Randomly select a block from the test case seed and replace it with random data or a block from another seed. This not only mutates a single message, but also mutates the order of message sequences, inserts / deletes messages, and tests the state machine logic. These mutation operations can be used in combination. The probability of each mutation operation can be adjusted to optimize test results; Generator 3104 records the seed number of the test cases after mutation by mutant 3102 and outputs it as a test case.

[0027] Among them, the data transmission module 4 uses various hardware and software to connect the fuzz test main controller 2, the parallel fuzz test engine 3 and the data transmission module 4 to ensure efficient data transmission.

[0028] Among them, the vehicle chip test bench 5, which consists of multiple non-invasive monitoring probe modules 6, probe support modules 7, vehicle chip support modules 8 and touch screen controllers 9, serves as a bridge for the interaction between the control system under test and the real hardware in the parallel fuzzy testing device 1, and is the key to testing the control system within the vehicle chip.

[0029] The non-intrusive monitoring probe 61, composed of a bus monitoring unit 6101 and a debug interface monitoring unit 6102, achieves efficient monitoring functions. The bus monitoring unit 6101 monitors the vehicle chip bus through independent hardware (such as CANoe / Vector tools), capturing the vehicle chip's response and the error frames it generates, without interfering with normal communication. The debug interface monitoring unit 6102 utilizes the debug ports of the vehicle chip (such as JTAG, DAP) and non-intrusively obtains program execution flow and abnormal interruption (such as MemManage, HardFault) information through the Trace function (such as ARM's ETM, Aurix's DAP). This is the most direct way to directly detect whether the control system has crashed.

[0030] The probe support module 7 consists of multiple multi-axis robotic arms 71, each corresponding to a non-invasive monitoring probe 61. The multi-axis robotic arms 71 control the position of the non-invasive monitoring probe 61, allowing the non-invasive monitoring probe 61 to be plugged into or disconnected from the interface on the vehicle chip.

[0031] The vehicle chip support module 8 is used to support and control the position of the vehicle chip. In the vehicle chip clamping structure 81, the clamp 8101 serves to clamp the vehicle chip. The sealing structure 8102 seals the clamped on-board chip; The temperature and pressure control structure 8103 adjusts the temperature and pressure values ​​within the sealed environment where the on-board chip is located.

[0032] The touchscreen controller 9 provides an operating platform for staff, enabling them to control the operation of the entire parallel fuzzy testing device 1. The reset control interface 91 outputs hardware signals to control the vehicle chip support module 8 to reset and adjust the position of the vehicle chip; Input the corresponding analog sensor input data (such as analog quantity, PWM signal) and actuator load data into the environmental simulation interface 92 to control the operation of the vehicle chip support module 8 to control the ambient temperature and pressure around the vehicle chip, so that the vehicle chip is in a more realistic working state and the practicality of the test results is guaranteed. The power control interface 93 uses programmable power technology to power on and off the vehicle chip after the control system crashes, and is responsible for controlling the emergency stop of various software and hardware to avoid overload damage to the vehicle chip during the operation of the parallel fuzzy testing device 1. The power consumption analysis module 94 monitors the power supply current of the vehicle chip. Abnormal power consumption spikes or drops are often indirect but effective indicators of vehicle chip lock-up or program crashes. This enables the parallel fuzzy testing device 1 to comprehensively collect data from different directions during the testing of the vehicle chip, ensuring the accuracy and comprehensiveness of the vehicle chip test evaluation.

[0033] In summary, the parallel fuzzy testing device 1, composed of a fuzzy testing main controller 2, a parallel fuzzy testing engine 3, a data transmission module 4, an on-board chip test bench 5, a non-intrusive monitoring probe module 6, a probe support module 7, an on-board chip support module 8, and a touch screen controller 9, can meet the fuzzy testing needs of one or more on-board chip control systems.

[0034] The parallel fuzzy testing device 1 in this application is used as follows: Example 1: Step 1: Hardware loading, control fixture 8101 to work and fix the vehicle chip, control multi-axis robotic arm 71 to work and drive non-invasive monitoring probe 61 to engage with the fixed vehicle chip, probe support module 7 and vehicle chip support module 8 cooperate to engage non-invasive monitoring probe 61 with the fixed vehicle chip.

[0035] Step 2: Initialization: The fuzz test main controller 2 randomly activates the test case seed and protocol syntax in the test case scheduler 21, the touch screen controller 9 starts the vehicle chip under test, and the non-intrusive monitoring probe 61 starts working.

[0036] Step 3: Scheduling and Distribution: The resource allocation unit 2103 dynamically adjusts the mutation strategy of the test cases based on the load capacity of the control system in the vehicle chip and monitoring feedback, and distributes the mutation strategy to an idle test case generation module 31.

[0037] Step 4: Mutation and Generation. The mutant 3102 mutates a seed test case within the syntactic framework specified by the protocol syntax 3103 to generate a new test case. In fuzz testing, it is necessary to determine the "energy" of each test case, that is, how many sub-test cases are generated based on the test case. Commonly used power scheduling algorithms are based on the coverage of test cases and the potential to find defects. This application uses the following formula to allocate energy to each test case, where f(t) is the coverage of test case t (i.e., the number of basic blocks covered), and T is the current set of test cases. Then, the energy p(t) of t can be calculated as follows:

[0038] Where P total The total energy is calculated using the above formula, which allows test cases with high coverage to obtain more energy, thereby improving the efficiency of test case application and reducing the energy input required for the operation of the parallel fuzz testing device 1.

[0039] Step 5: Execution and Monitoring: The test cases generated in the parallel fuzzy testing engine 3 are sent to the vehicle chip under test by the generator 3104 in order of priority through the data transmission module 4. The control system in the vehicle chip processes the data in the test cases, and the non-intrusive monitoring probe 61 starts to collect the running data of the vehicle chip at high frequency during the process of the control system processing the test cases. In the test case queue, test cases are sorted to prioritize those more likely to discover new paths or anomalies. This application uses a method based on coverage and novelty to determine priority, calculating a priority score for test case t using the following formula:

[0040] in, It is the set of basic blocks that are known to cover. α is the age of test case t (i.e., the time it was generated), and β are weight parameters. The above formula selects test cases that cover new code and recently generated test cases, so that the test cases most likely to find anomalies can be put into use quickly, increasing the speed at which test results change.

[0041] Step Six: Feedback and Analysis. The analysis results are as follows: Normal response: The system status monitor 22 did not detect any anomalies. The system status monitor 22 fed back the fuzzy test results of the test case to the crash analysis and manager 23. The test case scheduler 21 added this test case to the queue for further mutation. Abnormal Response: When the system status monitor 22 detects a control system crash (e.g., a HardFault is captured by the debug port), a freeze (e.g., a watchdog timeout), or a serious abnormality (e.g., a persistent bus error), it immediately triggers the following actions: First, implement crash management: save test cases and all monitoring data.

[0042] Next, perform a system recovery: the power control interface 93 in the touchscreen controller 9 restarts the vehicle chip; Finally, an analysis report is generated: the crash deduplication unit 2301 performs preliminary deduplication and classification of the test cases that trigger the crash, and performs stack trace-based analysis to avoid duplicate reporting of the same vulnerability; based on the records, the complete context of the crash moment is obtained, including test cases, system logs, memory snapshots, power consumption curves and other data, and the crash tracing model 2302 conducts in-depth analysis to trace the cause of the control system vulnerability; the test report generation unit 2303 summarizes the analysis results of the crash deduplication unit 2301 and the crash tracing model 2302 to generate a control system crash detail report, which is displayed on the touch screen controller 9.

[0043] Anomalies can be detected in the following ways: Crashes: System crashes (such as segmentation faults) can be detected using a debugger or watchdog timer; Resource anomalies: such as memory usage exceeding the threshold, excessively high CPU utilization, etc. Assertion failure: If the system has assertions, an assertion failure indicates an exception. Assume the control system has m indicators monitored by non-invasive monitoring probes 61, and the normal range for each indicator i is [L]. i U i For a specific test case t, the monitored metric value is... (t), then the abnormal score can be calculated as:

[0044] in It is an indicator function. It is the weight; if AnomalyScore(t) > 0, then the test case is marked as an anomaly.

[0045] Step 7: Cyclic Parallelism: During the fuzzy testing of a test case in the in-vehicle chip control system, if the system status monitor 22 does not detect any anomalies, the test case scheduler 21 marks this test case as a cyclic test case and adds it to the internal queue of the test case scheduler 21 for further mutation. After the mutation strategy is completed, the cyclic test case enters the internal queue of the parallel fuzzy testing engine 3 for deep mutation and is then put back into the fuzzy testing of the control system. This ensures the reasonable allocation of computing power of resources during the fuzzy testing of the in-vehicle chip control system. The main controller continuously schedules new tasks for other test cases. The whole process is highly parallelized and runs 24 / 7.

[0046] In summary, by employing multiple test case generation modules 31, multiple non-invasive monitoring probes 61, multiple multi-axis robotic arms 71, and multiple vehicle-mounted chip clamping structures 81, multiple vehicle-mounted chips can be clamped to perform parallel fuzz detection on the control systems within these chips. This fully utilizes multi-core computing resources and significantly improves testing efficiency. The resource allocation unit 2103 dynamically adjusts the mutation strategy of test cases based on the load capacity and monitoring feedback of the control systems within the vehicle-mounted chips. It considers the hardware characteristics and communication protocol range of the vehicle-mounted chips, ensuring accurate and efficient data collection during the testing of the control systems within the vehicle-mounted chips. Data collection is performed using non-invasive monitoring probes 61 that are highly compatible with the vehicle-mounted chips. Non-invasive monitoring ensures that the safety of the control system under test is not affected. The automated recovery mechanism provided by the touchscreen controller 9 ensures test continuity. In addition, the mutation strategy adjusted according to the load capacity and monitoring feedback of the control system effectively avoids damage to the hardware and software of the vehicle-mounted chips. Furthermore, the parallel fuzz testing engine 3 can explore code paths more quickly and discover deep vulnerabilities based on the coverage scheduling strategy.

[0047] Example 2: Based on Example 1: Step 1: Control the fixture 8101 to hold and fix the vehicle chip, and control multiple multi-axis robotic arms 71 to drive multiple non-invasive monitoring probes 61 to engage with different service unit interfaces in the fixed vehicle chip.

[0048] Step 2: Initialization proceeds normally.

[0049] Step 3: Scheduling and Distribution: The resource allocation unit 2103 dynamically adjusts the mutation strategy of the test cases based on the load capacity and monitoring feedback of each functional module in the vehicle chip control system, and distributes the mutation strategy to the parallel fuzzy testing engine 3.

[0050] Step 4: Mutation and Generation. Different test case generation modules 31 in the parallel fuzz testing engine 3 generate corresponding test cases according to their respective mutation strategies.

[0051] Step 5: Execution and Monitoring: The test cases generated in the parallel fuzzy testing engine 3 are transmitted to the vehicle chip under test by the generator 3104 in order of priority through the data transmission module 4. The corresponding functional unit of the control system in the vehicle chip processes the corresponding test cases, and the non-intrusive monitoring probe 61 starts to collect the running data of the vehicle chip during the fuzzy testing of the control system functional unit at a high frequency.

[0052] Step Six: Feedback and analysis proceed normally.

[0053] Step 7: The loop proceeds in parallel normally.

[0054] Step 8: Simulation test. Input the environmental simulation parameters through the environmental simulation interface 92. The sealing structure 8102 works to seal the on-board chip. The temperature and pressure control structure 8103 controls the internal temperature and air pressure of the space where the on-board chip is located according to the parameters, simulating the working environment of the on-board chip during vehicle operation.

[0055] Step nine; proceed with steps one, two, three, four, five, six, and seven.

[0056] In summary, the parallel fuzzy testing device 1 in this application, through the structural design of the parallel fuzzy testing engine 3 and the vehicle chip test bench 5, can individually test different functional units of a vehicle chip's control system. It can simulate situations where users use multiple vehicle functions simultaneously, accurately and quickly pinpointing the functional modules with vulnerabilities in the control system. Furthermore, by sealing the location of the vehicle chip and controlling the temperature around the chip, it simulates the most common working environment for high-frequency operation of the vehicle chip, ensuring the reference value of the fuzzy testing of the vehicle chip's control system for practical applications.

[0057] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. A parallel fuzzy testing device and method for in-vehicle chip control systems, comprising a parallel fuzzy testing device (1), characterized in that: The parallel fuzzing testing device (1) includes a fuzzing testing main controller (2), a parallel fuzzing testing engine (3), a data transmission module (4), and an on-board chip test bench (5). The fuzzing testing main controller (2) includes a test case scheduler (21), a system status monitor (22), and a crash analysis and manager (23). The test case scheduler (21) includes a seed queue management unit (2101), a power scheduling unit (2102), and a resource allocation unit (2103). The system status monitor (22) includes a bench data acquisition unit (2201), a system health assessment unit (2202), and a trigger automatic recovery unit (2203). The crash analysis and manager (23) includes a crash analysis and manager (23). The parallel fuzzing engine (3) includes multiple test case generation modules (31), including a fuzzer instance (3101), a mutant (3102), a protocol syntax (3103), and a generator (3104). The vehicle chip test bench (5) includes a non-intrusive monitoring probe module (6), a probe support module (7), a vehicle chip support module (8), and a touch screen controller (9). The non-intrusive monitoring probe module (6) includes multiple non-intrusive monitoring probes (61), and the vehicle chip support module (8) includes multiple vehicle chip clamping structures (81).

2. The parallel fuzzy testing device and method for in-vehicle chip control systems according to claim 1, characterized in that: The seed queue management unit (2101) is used to maintain a high-quality initial seed test case library, and the resource allocation unit (2103) dynamically adjusts the mutation strategy of the seed test cases according to the load capacity and monitoring feedback of the control system in the vehicle chip under test.

3. The parallel fuzzy testing device and method for in-vehicle chip control systems according to claim 1, characterized in that: The benchtop data acquisition unit (2201) continuously acquires the status of the tested control system from the non-invasive monitoring probe (61), and the trigger automatic recovery unit (2203) sends instructions to the control touch screen controller (9) when the tested control system freezes or crashes.

4. The parallel fuzzy testing device and method for in-vehicle chip control systems according to claim 1, characterized in that: The crash tracing model (2302) deeply analyzes and traces the causes of the control system vulnerability. The test report generation unit (2303) summarizes the analysis results of the crash deduplication unit (2301) and the crash tracing model (2302) to generate a control system crash details report.

5. The parallel fuzzy testing device and method for in-vehicle chip control systems according to claim 1, characterized in that: The protocol syntax (3103) is based on the vehicle communication protocol and the chip internal API specification, and the mutant (3102) performs intelligent mutation on the use case seed.

6. The parallel fuzzy testing device and method for in-vehicle chip control systems according to claim 1, characterized in that: The non-invasive monitoring probe (61) includes a bus monitoring unit (6101) and a debug interface monitoring unit (6102).

7. The parallel fuzzy testing device and method for in-vehicle chip control systems according to claim 1, characterized in that: The vehicle-mounted chip clamping structure (81) includes a clamp (8101), a sealing structure (8102), and a temperature and pressure control structure (8103).

8. The parallel fuzzy testing device and method for in-vehicle chip control systems according to claim 1, characterized in that: The probe support module (7) includes multiple multi-axis robotic arms (71) for controlling the position of the non-invasive monitoring probe (61).

9. The parallel fuzzy testing device and method for in-vehicle chip control systems according to claim 1, characterized in that: The touch screen controller (9) includes a reset control interface (91), an environment simulation interface (92), a power control interface (93), and a power consumption analysis module (94).

10. The parallel fuzzy testing device and method for in-vehicle chip control systems according to claim 1, characterized in that: Includes the following steps: Step 1: Hardware loading, the probe support module (7) and the vehicle chip support module (8) work together to connect the non-invasive monitoring probe (61) with the fixed vehicle chip; Step 2: Initialization: The fuzzy test main controller (2) starts working, the touch screen controller (9) starts the vehicle chip under test, and the non-invasive monitoring probe (61) starts working; Step 3: Scheduling and distribution. The resource allocation unit (2103) dynamically adjusts the variation strategy of test cases based on the load capacity of the control system in the vehicle chip and monitoring feedback. Step 4: Mutation and generation, the mutant (3102) mutates a seed use case within the syntactic framework specified by the protocol syntax (3103); Step 5: Execution and Monitoring: The test cases generated in the parallel fuzz test engine (3) are transmitted to the vehicle chip under test by the generator (3104) in order of priority through the data transmission module (4); Step 6: Feedback and Analysis, Normal Response: The system status monitor (22) does not detect any abnormality. The system status monitor (22) feeds back the test case results of the fuzzy test on the control system to the crash analysis and manager (23). The test case scheduler (21) adds this test case to the queue for further mutation. Abnormal Response: The system status monitor (22) detects that the control system has crashed, frozen, or is seriously abnormal. Step 7: Cyclic Parallelism. During the fuzzy testing of the control system within the vehicle chip, if the system status monitor (22) does not detect any abnormality, the test case scheduler (21) marks this test case as a cyclic test case and adds it to the internal queue of the test case scheduler (21) for further mutation. After the mutation strategy is completed, the cyclic test case enters the internal queue of the parallel fuzzy testing engine (3) for deep mutation and is then put back into the fuzzy testing of the control system.

Images