An intelligent terminal automatic test system and method based on a power consumption model

Abstract

The application discloses a kind of intelligent terminal automation test system and method based on power consumption model, specifically related to data processing field, including firmware analysis mapping module, instruction timing acquisition module, power consumption feature construction module, power consumption model adaptation module, use case coverage quantification module, power consumption anomaly positioning module and data traceability storage module;Firmware analysis mapping module: complete firmware analysis decoding, while establishing instruction-hardware unit mapping base library;Instruction timing acquisition module: anchor instruction execution timing, synchronously collect instruction-level power consumption data;Power consumption model adaptation module: fusion power consumption feature baseline, construct full instruction set power consumption model and adapt migration;The present application is based on the residual analysis of measured energy consumption data and model predicted energy consumption data, solves the problem of lack of power consumption anomaly root cause positioning capability in the prior art, only whole machine level power consumption statistics can be realized, greatly improves the efficiency and accuracy of intelligent terminal power consumption optimization.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and more specifically, to an automated testing system and method for smart terminals based on a power consumption model. Background Technology

[0002] In the field of digital data processing, automated testing systems are a core foundational tool for ensuring the functional compliance, performance stability, and reasonable power consumption of intelligent terminals (including embedded terminals, mobile intelligent devices, and IoT terminals) during their research and development and iteration. Existing technologies generally employ script-driven automated testing frameworks, combined with external hardware acquisition devices, to achieve unmanned batch execution of test cases and synchronous acquisition of terminal operating status data. These frameworks are widely used in core R&D stages such as terminal firmware iteration, driver compatibility verification, overall power consumption optimization, and scenario-based performance testing.

[0003] Existing automated testing systems have standardized and automated the testing process, replacing traditional manual testing methods, significantly improving the execution efficiency of test cases, and reducing random errors caused by manual operation. They can meet the basic testing needs before the mass production of smart terminals. However, core shortcomings remain: First, the power consumption testing of existing systems relies solely on hardware-collected global post-event statistical data at the whole-machine level. It lacks a refined mapping relationship between individual terminal test instructions, individual hardware drivers, and corresponding hardware unit power consumption data. The constructed power consumption model is only a global statistical model at the whole-machine level, unable to achieve instruction-level root cause localization of power consumption anomalies. Second, the test task execution engine and power consumption data acquisition module of existing systems are asynchronously decoupled. The collected power consumption data and the execution timing of test instructions have a fixed timestamp offset, making it difficult to achieve precise timing alignment at the instruction level, directly affecting the fitting accuracy of the power consumption model. First, the existing system lacks sufficient depth to reflect the true instruction-level power consumption characteristics of the terminal. Second, it fails to automatically migrate and adapt the power consumption model for smart terminals with different instruction set architectures and hardware configurations. For new terminal models, it is necessary to rebuild the test environment, calibrate the acquisition parameters, and reconstruct the power consumption model, resulting in extremely poor system versatility and reusability. Third, the existing system does not achieve quantitative characterization of full-condition power consumption coverage of test cases based on the power consumption model. There is a problem that the test cases cannot cover the high-power edge conditions and low-power sleep conditions of the terminal, which directly leads to insufficient test completeness and makes it impossible to identify power consumption anomalies under extreme conditions of the terminal in advance.

[0004] Therefore, to address the aforementioned shortcomings of existing technologies, an automated testing system and method for intelligent terminals based on power consumption models is needed. This system would construct a static mapping system between instructions and hardware units to achieve precise timing alignment between test instructions and power consumption data at the instruction level. Based on the collected refined data, a full instruction set power consumption model that can be migrated across terminals would be constructed. Simultaneously, the system would complete the full-condition power consumption coverage quantification of test cases and the instruction-level root cause localization of power consumption anomalies. This would solve the core problems of insufficient power consumption model accuracy, lack of root cause localization capability, poor system reusability, and insufficient test completeness in existing technologies. Summary of the Invention

[0005] To overcome the aforementioned deficiencies in the prior art, this invention provides an automated testing system and method for smart terminals based on a power consumption model, which addresses the problems mentioned in the background section through the following solutions.

[0006] To achieve the above objectives, the present invention provides the following technical solution: an automated testing system for intelligent terminals based on a power consumption model, comprising: Firmware parsing and mapping module: completes firmware parsing and decoding, and establishes the basic library for instruction-hardware unit mapping; Instruction timing acquisition module: anchors instruction execution timing and synchronously acquires instruction-level power consumption data; Power consumption feature construction module: Based on the collected energy consumption data, extract power consumption features and construct a power consumption baseline; Power consumption model adaptation module: integrates power consumption feature baselines, constructs a full instruction set power consumption model, and adapts it for migration; Test case coverage quantization module: calls the power consumption model, parses test cases, and quantifies the power consumption coverage under all operating conditions; Power consumption anomaly localization module: compares the model with the measured data to complete the instruction-level root cause localization of power consumption anomalies; Data traceability and storage module: Integrates data from the entire process and builds a traceability system to achieve a closed loop of the entire data chain.

[0007] Preferably, the firmware parsing and decoding is used to complete the static unpacking and segmented parsing of the firmware image to be tested on the smart terminal. For encrypted firmware, the firmware memory image running inside the chip is read through the terminal hardware debugging interface to bypass static encryption verification. At the same time, by parsing the segment table information of the firmware, binary segments with segment types of executable code and segment names matching the characteristics of the driver are identified. Combined with the hardware register mapping address, the complete driver binary segment is located and extracted to obtain the instruction set architecture type of the firmware image. Driver binary segment base address Driver binary segment length Based on the extracted instruction set architecture type; Based on the official instruction set architecture manual, a decoding rule base for the corresponding instruction set is constructed. A mapping relationship is established between opcodes, instruction semantics, and hardware call entry points. This completes line-by-line decoding of the machine code within the driver's binary segment, obtaining the opcode, addressing mode, target register, and hardware call entry point for each machine instruction. The instruction-hardware unit mapping base library is built based on the decoding results, storing the opcode of each machine instruction and the corresponding subset of calling hardware units. Driver call address offsets corresponding to each hardware unit This achieves complete binding of a single machine instruction to all associated terminal hardware units; the driver call address offset ,in For a single test command The corresponding driver call entry address.

[0008] Preferably, the specific method for synchronously acquiring instruction-level power consumption data is as follows: timing anchoring probes are embedded at the entry point of the processor instruction execution queue and the exit point of the write-back stage. The probes are implemented using the hardware breakpoint read-only mechanism of the hardware debugging interface, without modifying instruction data, occupying processor execution clock cycles, or changing the normal execution timing of instructions, and capturing a single test instruction. execution start timestamp With execution end timestamp Simultaneously, a hardware trigger signal for differential transmission is generated based on the captured timestamp. The sampling clock of the external power consumption acquisition device is from the same source as the processor's system clock, with a synchronization accuracy deviation of no more than one sampling clock cycle. This synchronously drives the acquisition device to acquire a single test command. corresponding hardware unit within the execution cycle Real-time power supply voltage With real-time operating current Furthermore, a unique timing tag is bound to the collected power consumption data, consistent with the corresponding test instruction. Based on the timestamps of each stage of the pipeline for a single instruction, the time window occupied by the hardware unit is determined. Combining the hardware call priority of the instruction with the clock cycle occupancy ratio, the single test instruction is finally obtained. corresponding hardware unit within the execution cycle instruction-level power consumption ,in The sampling point number, The total number of sampling points. , and , These represent the i-th hardware unit within the execution cycle of a single test instruction. The and the first Each sampling time point and The collected real-time power supply voltage and current values, The time interval between adjacent sampling points enables precise separation of power consumption data for a single instruction in a superscalar pipeline architecture.

[0009] Preferably, the power consumption characteristics are based on the collected instruction-level power consumption data, traversing all hardware units corresponding to the test instructions. instruction-level power consumption Extract power consumption characteristic parameters of hardware units, including power consumption benchmark per unit clock cycle. Address offset-related power consumption correction factor The calibration parameters include: idle-state static power consumption; and hardware unit parameter calibration based on clearly defined operating conditions: idle state is defined as a stable operating state with no instruction calls and the clock frequency maintaining the rated minimum value; full-load state is defined as a stable operating state with the clock frequency maintaining the rated maximum value while continuously executing the benchmark test instruction set; the calibration parameters include hardware unit... Static power consumption Minimum static power consumption Peak power consumption Minimum resolution step size of power consumption range The power consumption baseline is constructed based on extracted power consumption feature parameters and is divided into each hardware unit. The static power consumption baseline and dynamic power consumption baseline are determined. The static power consumption baseline is the energy consumption per unit time when the hardware unit is in an idle state without instruction calls, and the dynamic power consumption baseline is the energy consumption change per unit clock cycle when the hardware unit responds to a single instruction call. Finally, the energy consumption benchmark per unit clock cycle is obtained. Energy correction factor related to address offset ,in To call hardware unit The set of test instructions, For a single test command Number of clock cycles used For a single test command Execution time.

[0010] Preferably, the full instruction set power consumption model is constructed based on power consumption characteristic parameters and power consumption baseline, combined with the instruction-hardware unit mapping base library and measured instruction-level energy consumption data; using a single test instruction... opcode, target hardware unit, number of clock cycles Driver call address offset As input, output the predicted energy consumption value of the corresponding hardware unit during the execution of this instruction. The adaptation and migration involves designing an automated execution process across terminals and architectures, which includes: extracting core information from the target terminal firmware; extracting power consumption features and constructing a power consumption baseline for the target terminal hardware units; constructing the instruction-hardware unit mapping relationship; adapting and matching model input parameters; generating a power consumption model specific to the target terminal; and characterizing the model prediction accuracy. The predicted energy consumption value... ,in This refers to the actual execution time of a single test instruction I. For instruction-hardware unit mapping indication functions, when the instruction Call hardware unit hour ,otherwise .

[0011] Preferably, the parsed test cases are based on the constructed full instruction set power consumption model to complete the test case set to be verified. Full static analysis is performed to break down the data into individual test cases. Included test instruction sequence The full-condition power consumption coverage is based on a full instruction set power consumption model, analyzing each hardware unit during test case execution. The cumulative predicted energy consumption, the covered power consumption characteristic range, and the covered instruction opcode types are used to divide the hardware units. Test case sets are generated from three consecutive intervals: low power consumption, rated power consumption, and high power consumption. The instruction-level power consumption coverage quantization results are used to obtain the hardware unit. power consumption range coverage length and test case set Overall power consumption coverage ,in This is a power consumption range coverage indication function.

[0012] Preferably, the instruction-level root cause localization of power consumption anomalies is based on a full instruction set power consumption model and measured instruction-level energy consumption data. Using the unique timing label of each test instruction as a basis, instruction-by-instruction timing alignment of measured instruction-level energy consumption data and predicted energy consumption data is completed, and individual test instructions are extracted. Energy consumption residual data Based on the instruction-hardware unit mapping library, the energy consumption residual data is mapped to the corresponding hardware units. The process involves mapping the driver's call address segment, generating a ranking of hardware unit power consumption anomalies based on their contribution, locating the abnormal hardware unit and its corresponding abnormal instruction set, generating a power consumption anomaly root cause localization report, which includes the opcode of the abnormal instruction, the corresponding hardware unit, the driver address offset, the power consumption residual value, and a unique timing tag. Finally, a single test instruction is obtained. Energy consumption residual Hardware unit Overall energy consumption residual sum of squares and hardware units Contribution to overall power consumption anomalies ,in For the kth hardware unit The corresponding sum of squares of the overall energy consumption residuals.

[0013] Preferably, the traceability system is used to integrate full-process test data, construct a full-link traceability data structure, and complete the structured association of test process data. The associated data includes firmware image parsing data, instruction-hardware unit mapping data, test instruction timing anchoring data, hardware unit power consumption acquisition data, power consumption model parameter data, test case coverage data, and power consumption anomaly root cause location data. Simultaneously, it is used to generate unique traceability identifiers that are one-to-one bound to the core test elements. The traceability identifier is generated by combining the unique timing tag of the test instruction, the firmware image version number, and the terminal hardware serial number. The data full-link closed loop completes the non-relational timing database storage of the full-link test data and constructs a corresponding data retrieval index. The index fields include firmware version number, hardware unit type, instruction opcode, timing tag, and power consumption anomaly identifier, enabling rapid retrieval and full-link traceability of test data.

[0014] Preferably, an automated testing method for smart terminals based on a power consumption model includes the following steps: S1. Complete firmware parsing and decoding, and establish the instruction-hardware unit mapping basic library; S2. Anchor instruction execution timing and synchronously collect instruction-level power consumption data; S3. Based on the collected energy consumption data, extract power consumption characteristics and construct a power consumption baseline. S4. Integrate power consumption characteristic baselines, construct a full instruction set power consumption model, and adapt it for migration; S5. Call the power consumption model to parse test cases and quantify the power consumption coverage under all operating conditions; S6. Compare the model with the measured data to complete the instruction-level root cause localization of power consumption anomalies; S7. Integrate data across the entire process to build a traceability system and achieve a closed loop for the entire data chain.

[0015] The technical effects and advantages of this invention are as follows: 1. This invention achieves precise alignment of test instructions with the power consumption data of smart terminal hardware units through a firmware parsing and mapping module and an instruction timing acquisition module. It completes accurate energy consumption analysis of the hardware unit corresponding to a single instruction through a second-order trapezoidal numerical integration algorithm. At the same time, it establishes a full mapping relationship between a single instruction and all associated hardware units, solving the problems of power consumption data and test instruction timing offset and the lack of a mapping relationship between instructions and hardware unit power consumption in the prior art. It realizes fine-grained power consumption data acquisition and mapping at the instruction level, which greatly improves the accuracy and traceability of power consumption data. 2. Based on the extracted hardware unit power consumption feature parameters, this invention constructs a full instruction set power consumption model with instruction opcode, hardware unit, clock cycle count, and address offset as inputs. At the same time, it designs a complete cross-terminal and cross-architecture automated migration and adaptation process, realizing the automated migration and adaptation of the power consumption model between smart terminals with different firmware versions and different hardware configurations. This solves the problems of insufficient fitting accuracy, poor universality and reusability of power consumption models in the prior art. It eliminates the need to rebuild the test environment and calibrate the acquisition parameters for different terminals, greatly improving the adaptability and deployment efficiency of the automated test system. 3. Based on the constructed power consumption model and the full power consumption range of the hardware unit, this invention completes the quantitative characterization of the coverage of the test case set for the full power consumption of each hardware unit of the terminal. It solves the problems of insufficient power consumption coverage and test completeness of the test cases in the prior art. It realizes the quantitative evaluation of the test coverage of the smart terminal under the full power consumption, rated power consumption and high power consumption conditions, and provides accurate data support for the optimization and completeness verification of the test case set. 4. Based on residual analysis of measured energy consumption data and model predicted energy consumption data, this invention completes the quantification of hardware unit contribution and instruction-level root cause localization of power consumption anomalies. It solves the problems of lack of root cause localization capability for power consumption anomalies in the prior art and only being able to achieve whole-machine level power consumption statistics. It can accurately locate the opcode, hardware unit and driver address offset corresponding to the abnormal instruction, which greatly improves the efficiency and accuracy of power consumption optimization of smart terminals. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the system structure of the present invention; Figure 2 This is a schematic diagram of the method flow of the present invention. Detailed Implementation

[0017] 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.

[0018] As attached Figure 1 The system shown is an automated testing system for smart terminals based on a power consumption model, which includes a firmware parsing and mapping module, an instruction timing acquisition module, a power consumption feature construction module, a power consumption model adaptation module, a test case coverage quantization module, a power consumption anomaly location module, and a data traceability and storage module.

[0019] The firmware parsing and mapping module: completes firmware parsing and decoding, and establishes a basic library for instruction-hardware unit mapping; In this embodiment, it should be noted that: the firmware parsing and decoding is used to complete the static unpacking and segmented parsing of the firmware image to be tested on the smart terminal. For encrypted firmware, the firmware memory image running inside the chip is read through the terminal hardware debugging interface to bypass the static encryption verification; at the same time, by parsing the segment table information of the firmware, binary segments with segment types of executable code and segment names matching the characteristics of the driver are identified. Combined with the hardware register mapping address, the complete driver binary segment is located and extracted to obtain the instruction set architecture type of the firmware image. Driver binary segment base address Driver binary segment length Based on the extracted instruction set architecture type; Based on the official instruction set architecture manual, a decoding rule base for the corresponding instruction set is constructed. A mapping relationship is established between opcodes, instruction semantics, and hardware call entry points. This completes line-by-line decoding of the machine code within the driver's binary segment, obtaining the opcode, addressing mode, target register, and hardware call entry point for each machine instruction. The instruction-hardware unit mapping base library is built based on the decoding results, storing the opcode of each machine instruction and the corresponding subset of calling hardware units. Driver call address offsets corresponding to each hardware unit This achieves complete binding of a single machine instruction to all associated terminal hardware units; the driver call address offset ,in For a single test command The corresponding driver call entry address. In detail, this module performs operations during the pre-testing phase before the start of the automated testing task for the smart terminal. For the firmware image of the smart terminal to be tested (including encrypted firmware from the manufacturer and firmware scenarios with different instruction set architectures), it completes firmware parsing and decoding and establishes the instruction-hardware unit mapping relationship. The specific execution process is as follows: First, static unpacking and segmented parsing are performed on the firmware image of the smart terminal to be tested. For encrypted firmware, the firmware memory image running inside the chip is read through the terminal hardware debugging interface to bypass the static encryption verification of the firmware. Then, the segment table information of the firmware is parsed to identify binary segments whose segment type is executable code and whose segment name matches the characteristics of the driver. Combined with the hardware register mapping address, the complete driver binary segment is located and extracted. Simultaneously, the instruction set architecture type corresponding to the firmware, the base address of the driver binary segment, and its length information are obtained. Subsequently, based on the extracted instruction set architecture type, the corresponding official instruction set is used... The architecture manual constructs a matching decoding rule base, establishing a one-to-one mapping relationship between opcodes, instruction semantics, and hardware call entry points. This decoding rule base is used to decode the machine code within the driver's binary segment line by line, obtaining the opcode, addressing mode, target register, and hardware call entry point corresponding to each machine instruction. Finally, based on the decoding results, a basic instruction-hardware unit mapping library is built. This library stores the opcode of each machine instruction, the corresponding subset of calling hardware units, and the driver call address offset for each hardware unit, completing the full binding of a single machine instruction to all associated terminal hardware units. This provides basic mapping data for subsequent full-process testing. The intelligent terminal hardware unit set... , The i-th hardware unit specifically includes an application processor core, a graphics processor, a modem, a memory controller, a storage controller, a power management unit, and a peripheral interface controller. A single instruction I corresponds to a subset of the hardware units that are called. U, the number of hardware units within the subset .

[0020] The instruction timing acquisition module: anchors the instruction execution timing and synchronously acquires instruction-level power consumption data; In this embodiment, it should be noted that the specific method for synchronously acquiring instruction-level power consumption data is as follows: timing anchoring probes are embedded at the entry point of the processor instruction execution queue and the exit point of the write-back stage. The probes are implemented using the hardware breakpoint read-only mechanism of the hardware debugging interface, without modifying instruction data, occupying the processor execution clock cycle, or changing the normal execution timing of the instructions, and capturing a single test instruction. execution start timestamp With execution end timestamp Simultaneously, a hardware trigger signal for differential transmission is generated based on the captured timestamp. The sampling clock of the external power consumption acquisition device is from the same source as the processor's system clock, with a synchronization accuracy deviation of no more than one sampling clock cycle. This synchronously drives the acquisition device to acquire a single test command. corresponding hardware unit within the execution cycle Real-time power supply voltage With real-time operating current Furthermore, a unique timing tag is bound to the collected power consumption data, consistent with the corresponding test instruction. Based on the timestamps of each stage of the pipeline for a single instruction, the time window occupied by the hardware unit is determined. Combining the hardware call priority of the instruction with the clock cycle occupancy ratio, the single test instruction is finally obtained. corresponding hardware unit within the execution cycle instruction-level power consumption ,in The sampling point number, The total number of sampling points. , and , These represent the i-th hardware unit within the execution cycle of a single test instruction. The and the first Each sampling time point and The collected real-time power supply voltage and current values, This module establishes the time interval between adjacent sampling points to achieve precise separation of power consumption data for the hardware unit corresponding to a single instruction in a superscalar pipelined architecture. Specifically, during the execution of automated test cases, this module covers the entire lifecycle from the entry of a single test instruction into the processor execution queue to its completion. In intelligent terminal processor operating environments and scenarios involving external power consumption acquisition devices (including scenarios where multiple instructions overlap in execution under a processor's superscalar pipelined architecture), it achieves precise anchoring of the test instruction execution timing and synchronous acquisition and precise separation of corresponding hardware unit power consumption data. The specific execution process is as follows: First, timing anchoring probes are embedded at the entry point of the processor's instruction execution queue and the exit point of the write-back stage. These probes are implemented using a hardware breakpoint read-only mechanism of the hardware debug interface, ensuring they do not modify instruction data, occupy processor execution clock cycles, or alter the normal execution timing of instructions. At the instant a single test instruction enters the processor's execution queue, the probe reads the instruction information through the instruction execution queue's status register, capturing the instruction's execution start timestamp. At the instant the instruction completes the pipeline write-back stage, the probe captures the instruction's execution end timestamp through the write-back stage's completion flag. Based on the captured start and end timestamps, a hardware trigger signal using differential transmission is generated and synchronously sent to an external power consumption acquisition device. Simultaneously, the sampling clock of the external power consumption acquisition device is kept synchronized with the processor's system clock, controlling the synchronization accuracy deviation to within one sampling hour. Within a clock cycle, the driver acquisition device starts high-frequency acquisition of the corresponding hardware unit acquisition channel at the start of instruction execution and stops acquisition of the corresponding channel at the end of instruction execution. During the acquisition process, each set of acquired power consumption data is labeled with a unique timing tag that is completely consistent with the corresponding test instruction. For scenarios where multiple instructions are executed concurrently under the processor's superscalar pipeline architecture, the hardware unit occupancy time window of the instruction is first determined based on the timestamps of each stage of the pipeline of a single instruction. Then, for the same hardware unit, the power consumption ratio of multiple instructions within the same time window is split by combining the hardware call priority and clock cycle occupancy ratio of the instruction. This completes the accurate separation of the power consumption data of the hardware unit corresponding to a single instruction, and finally obtains the real-time power supply voltage and real-time operating current timing data of the associated hardware unit within the execution cycle of a single instruction, providing accurate basic data for subsequent energy consumption calculation and feature extraction.

[0021] The power consumption feature construction module extracts power consumption features and constructs a power consumption baseline based on the collected energy consumption data. In this embodiment, it should be noted that the power consumption characteristics are based on the collected instruction-level power consumption data, traversing all hardware units corresponding to the test instructions. instruction-level power consumption Extract power consumption characteristic parameters of hardware units, including power consumption benchmark per unit clock cycle. Address offset-related power consumption correction factor The calibration parameters include: idle-state static power consumption; and hardware unit parameter calibration based on clearly defined operating conditions: idle state is defined as a stable operating state with no instruction calls and the clock frequency maintaining the rated minimum value; full-load state is defined as a stable operating state with the clock frequency maintaining the rated maximum value while continuously executing the benchmark test instruction set; the calibration parameters include hardware unit... Static power consumption Minimum static power consumption Peak power consumption Minimum resolution step size of power consumption range The power consumption baseline is constructed based on extracted power consumption feature parameters and is divided into each hardware unit. The static power consumption baseline and dynamic power consumption baseline are determined. The static power consumption baseline is the energy consumption per unit time when the hardware unit is in an idle state without instruction calls, and the dynamic power consumption baseline is the energy consumption change per unit clock cycle when the hardware unit responds to a single instruction call. Finally, the energy consumption benchmark per unit clock cycle is obtained. Energy correction factor related to address offset ,in To call hardware unit The set of test instructions, For a single test command Number of clock cycles used For a single test command The execution time is as follows. In detail, this module performs operations after acquiring power consumption data for a single batch of test instructions and obtaining instruction-level energy consumption data. It targets all types of hardware units within the smart terminal, covering all operating conditions including idle and full-load states. It completes the extraction of hardware unit power consumption characteristic parameters, key parameter calibration, and the construction of a standardized power consumption baseline. Specifically, the execution process is as follows: First, based on the previously acquired instruction-level power consumption timing data, the instruction-level energy consumption of the corresponding hardware unit within each test instruction execution cycle is calculated. Then, for each hardware unit, the instruction-level energy consumption data corresponding to all test instructions that have called that hardware unit is traversed, extracting the power consumption characteristic parameters of that hardware unit under different clock cycles and different driver call address offsets, including the unit clock cycle energy consumption baseline, address offset-related energy consumption correction factors, and idle-state static power consumption values. Simultaneously, the calibration of key operating parameters of the hardware unit is completed. The idle state of the hardware unit is clearly defined as a stable operating state with no instruction calls and the clock frequency maintaining the minimum rated value. The full-load state... The system operates in a stable state where the benchmark test instruction set is continuously executed and the clock frequency is maintained at the rated maximum value. Based on the calibrated operating conditions, the static power consumption, minimum static power consumption, and peak power consumption of the hardware unit are collected. At the same time, one-thousandth of the peak power consumption of the hardware unit is taken as the minimum resolution step size of the power consumption range. Finally, based on the extracted power consumption characteristic parameters, a static power consumption baseline and a dynamic power consumption baseline are constructed for each hardware unit. The static power consumption baseline is the energy consumption value per unit time when the hardware unit is in an idle state without instruction calls, and the dynamic power consumption baseline is the energy consumption change value per unit clock cycle when the hardware unit responds to a single instruction call. This provides standardized benchmark data for the construction of subsequent power consumption models.

[0022] The power consumption model adaptation module: integrates power consumption feature baselines, constructs a full instruction set power consumption model, and adapts it for migration; In this embodiment, it should be noted that: the full instruction set power consumption model is constructed based on power consumption characteristic parameters and power consumption baseline, combined with the instruction-hardware unit mapping basic library and measured instruction-level energy consumption data; using a single test instruction... opcode, target hardware unit, number of clock cycles Driver call address offset As input, output the predicted energy consumption value of the corresponding hardware unit during the execution of this instruction. The adaptation and migration involves designing an automated execution process across terminals and architectures, which includes: extracting core information from the target terminal firmware; extracting power consumption features and constructing a power consumption baseline for the target terminal hardware units; constructing the instruction-hardware unit mapping relationship; adapting and matching model input parameters; generating a power consumption model specific to the target terminal; and characterizing the model prediction accuracy. The predicted energy consumption value... ,in This refers to the actual execution time of a single test instruction I. For instruction-hardware unit mapping indication functions, when the instruction Call hardware unit hour ,otherwise In detail, this module performs core operations after extracting hardware unit power consumption features and building a power consumption baseline. It also covers scenarios for testing and adapting to new target smart terminals, and for cross-terminal adaptation scenarios involving the currently tested smart terminals and different instruction set architectures and hardware configurations. It completes the construction of a refined power consumption model for the entire instruction set and the automated migration and adaptation of the power consumption model across terminals and architectures. The specific execution process is as follows: First, based on the previously built instruction-hardware unit mapping library, the completed hardware unit power consumption baseline, and the measured instruction-level energy consumption data, a full instruction set power consumption model is built. This model takes the opcode of a single test instruction, the target hardware unit, the number of clock cycles, and the driver call address offset as input, and can output the predicted energy consumption value of the corresponding hardware unit during the execution of this instruction. For target smart terminals with different instruction set architectures and hardware configurations, a standardized automated migration and adaptation process is executed. The first step is to extract the instruction set architecture type and hardware unit of the target terminal firmware through the firmware parsing and mapping module. The process involves five steps: first, extracting the core information of the metaset and driver binary segment; second, reusing the system's built-in power consumption feature extraction logic to extract power consumption feature parameters and build a power consumption baseline for each hardware unit of the target terminal; third, matching the corresponding decoding rule library based on the instruction set architecture type of the target terminal to build the instruction-hardware unit mapping relationship; fourth, adapting and matching the model input parameters based on the hardware parameters of the target terminal to generate a dedicated power consumption model adapted to the target terminal; and fifth, characterizing the model prediction accuracy through a benchmark test instruction set. Finally, the entire process of automated migration and adaptation is completed without the need for manual parameter recalibration or model framework reconstruction.

[0023] This module is the core module of the model, responsible for building the model architecture, training convergence, and cross-terminal migration and adaptation. All the design of the model is based on the scenario requirements of automated power consumption testing of smart terminals, and it is fully compatible with the entire data link of this system.

[0024] The core architecture, hierarchical modules, and connection relationships of the model: This model is a hierarchical relational model designed for refined power consumption prediction of a single machine instruction in a smart terminal. It adopts a serial, progressive hierarchical architecture, with five core levels set sequentially from input to output. Data is transferred between adjacent levels using a forward fully connected approach, with no cross-level skip connections. The function of each level is fully adapted to the needs of automated power consumption testing scenarios for smart terminals. The specific hierarchical and connection relationships are as follows: The first layer is the input adaptation layer, which is the entry level of the model. It is responsible for receiving input data that is strongly related to standardization processing and testing scenarios, completing the unification of input data formats under different instruction set architectures and different hardware configurations, providing standardized input information for subsequent layers, and is the basic layer to ensure that the model can adapt to multiple types of terminals. The second layer is the hardware unit power consumption feature mapping layer, which takes over the standardized output of the input adaptation layer. It is responsible for associating the standardized power consumption baseline data of the hardware unit, establishing the mapping relationship between the input information and the inherent power consumption characteristics of the corresponding hardware unit, and matching the power consumption feature parameters of the corresponding hardware unit. It is the core connection layer connecting the physical characteristics of the hardware and the instruction execution behavior. The third layer is the instruction semantic-energy consumption association layer, which takes over the output of the hardware unit power consumption feature mapping layer. It is responsible for establishing the relationship between instruction execution behavior and dynamic energy consumption changes of hardware units based on the core execution information of instructions, and restoring the dynamic power consumption changes of hardware units caused by a single instruction execution process. It is the core computing layer for achieving accurate prediction of instruction-level power consumption. The fourth layer is the multi-hardware unit energy consumption fusion layer, which takes over the output of the instruction semantic-energy consumption association layer. It is responsible for handling real test scenarios where a single instruction calls multiple hardware units at the same time, integrating the predicted energy consumption data of multiple associated hardware units, and outputting the energy consumption details and summary data of all associated hardware units corresponding to a single instruction. The fifth layer is the output layer, which is the exit layer of the model. It receives the output of the energy consumption fusion layer of multiple hardware units and outputs the predicted energy consumption results corresponding to a single instruction in a formatted manner according to the data application requirements of the automated test scenario, providing standardized prediction data for subsequent testing stages.

[0025] The specific steps of model training and construction are as follows: The training and construction of this model are entirely based on the automated power consumption testing scenario of smart terminals. All training data comes from the actual compliant data of the preceding modules within this system. No external third-party datasets are required throughout the process, ensuring the model's adaptability to the test terminal's scenario. The specific steps of training and construction are as follows: Step 1: Preparation and preprocessing of the training dataset. Before model construction, the firmware parsing and mapping module completes the parsing of the test terminal's firmware and the construction of the instruction-hardware unit mapping basic library. Then, the instruction timing acquisition module completes the execution timing anchoring of batch benchmark test instruction sets and the synchronous acquisition of instruction-level power consumption data of corresponding hardware units. Finally, the power consumption feature construction module completes the extraction of power consumption features of hardware units and the construction of standardized power consumption baselines, ultimately forming the basic dataset for model training. Each sample in the dataset corresponds one-to-one with the complete execution information of a single instruction, the actual energy consumption data of the corresponding hardware unit, and the standardized power consumption baseline data of the hardware unit, perfectly matching the model's input and output requirements. All data comes from the real operating scenario of the test terminal. Step 2: Step-by-step training and parameter convergence at the model level. First, the overall hierarchical architecture of the model is fixed, and training is carried out step by step from the bottom to the top. The input adaptation layer is trained first to standardize and adapt to different input data formats, ensuring that input data from different instruction set architectures and different hardware units can be uniformly recognized by the model. Next, the hardware unit power consumption feature mapping layer is trained, using the standardized power consumption baseline of the hardware unit as a benchmark, to complete the mapping relationship between input information and the corresponding hardware unit power consumption features, ensuring that the model can accurately match the inherent power consumption characteristics of the hardware unit corresponding to the instruction. Finally, the instruction semantic-energy consumption association layer is trained, using the measured energy consumption data of a single instruction as the training benchmark. The training process involves three main steps: First, training the model to establish the correlation between instruction execution behavior and dynamic power consumption changes in hardware units. This ensures the model accurately reflects the dynamic power consumption changes triggered by instruction execution. Next, a multi-hardware unit power consumption fusion layer is trained, using the combined measured power consumption data of multiple hardware units called by a single instruction as a benchmark to integrate and match the power consumption of multiple hardware units. Finally, formatted adaptation training of the output layer is completed to ensure the output results meet the application requirements of subsequent testing. Each training level aims to minimize the deviation between the predicted results and the measured data, achieving parameter convergence within each level and seamless adaptation between adjacent levels to ensure the overall model's prediction accuracy. The third step involves model accuracy verification and optimization. After completing training at all levels, a reserved benchmark test instruction set not used in the training is used to verify the model's accuracy. The predicted power consumption results output by the model are compared with the actual power consumption data measured by the instruction timing acquisition module to verify the model's prediction accuracy. If the accuracy does not meet the requirements of the test scenario, the verification data is added to the training dataset, and incremental training and parameter optimization are performed on the model until the model's prediction accuracy meets the requirements of automated power consumption testing for smart terminals, thus completing the final model construction.

[0026] Model cross-terminal and cross-scenario migration and adaptation implementation: For smart terminal test scenarios with different instruction set architectures and hardware configurations, this model supports automated migration and adaptation without the need to retrain the model from scratch, significantly reducing the cost of setting up a new terminal test environment. The specific implementation process of migration and adaptation combined with the new scenario is as follows: First, the firmware parsing and mapping module completes the firmware parsing, instruction set architecture identification, and instruction-hardware unit mapping basic library construction of the new target terminal, obtaining basic scenario information such as the hardware unit composition and instruction set rules of the new terminal; Second, the instruction timing acquisition module and power consumption feature construction module complete the power consumption of each hardware unit of the new target terminal. Feature extraction and standardized power consumption baseline construction are performed to obtain the inherent power consumption characteristics of the new terminal hardware units. Subsequently, the core architecture and related logic of the instruction semantic-energy consumption correlation layer, multi-hardware unit energy consumption fusion layer, and output layer in the original model are fixed. Adaptation fine-tuning training is carried out only for the input adaptation layer and the hardware unit power consumption feature mapping layer. The training data adopts the benchmark test instruction set of the new target terminal to complete the adaptation of the hardware characteristics, instruction set rules and core architecture of the new terminal. Finally, the accuracy of the adapted model is verified. After the verification is passed, a dedicated power consumption model adapted to the new target terminal is generated, realizing the rapid reuse of the model in different smart terminal test scenarios.

[0027] The intrinsic relationship between model input, output, and test scenario: The input and output of this model are designed entirely around the requirements of the entire process of automated power consumption testing for smart terminals, and are completely closed-loop with the intrinsic relationship with the scenario, as follows: The input data of the model all come from the real scenario data generated by the preceding modules of this system for the terminal under test. Specifically, this includes the opcode information of a single test instruction, the target hardware unit information corresponding to the instruction, the clock cycle information of the instruction execution, and the driver call address offset information corresponding to the instruction. All input data are directly related to the real firmware and hardware characteristics of the terminal under test, ensuring that the model's prediction results are completely matched to the current terminal scenario being tested, rather than generalized irrelevant data. The output data of the model is the predicted energy consumption details of all associated hardware units during the execution of a single test instruction, as well as the overall predicted energy consumption summary data of a single instruction. The output data directly connects to the subsequent automated testing stages, providing core benchmark data for the power consumption coverage calculation of the test case coverage quantification module and the energy consumption residual analysis of the power consumption anomaly localization module, fully serving the requirements of the entire process of automated testing for smart terminals.

[0028] The test case coverage quantification module calls the power consumption model to parse the test cases and quantify the power consumption coverage under all operating conditions. In this embodiment, it should be noted that the parsed test cases are based on the constructed full instruction set power consumption model to complete the test case set to be verified. Full static analysis is performed to break down the data into individual test cases. Included test instruction sequence The full-condition power consumption coverage is based on a full instruction set power consumption model, analyzing each hardware unit during test case execution. The cumulative predicted energy consumption, the covered power consumption characteristic range, and the covered instruction opcode types are used to divide the hardware units. Test case sets are generated from three consecutive intervals: low power consumption, rated power consumption, and high power consumption. The instruction-level power consumption coverage quantization results are used to obtain the hardware unit. power consumption range coverage length and test case set Overall power consumption coverage ,in For power consumption range coverage indication function, when the test case set There exists at least one test instruction that causes the hardware unit to execute when the instruction is executed. The instantaneous power consumption is at When within the interval, =1, otherwise =0, For target hardware unit Instantaneous power consumption reference value, It is the minimum resolution step size within the power consumption range. In detail, this module operates after the full instruction set power consumption model is built but before the formal execution of batch automated testing tasks. It can also be applied to scenarios involving test case set optimization and iteration. For the full set of test cases to be verified, it covers low-power, rated-power, and high-power full-condition scenarios for each hardware unit of the smart terminal, completing test case parsing and quantitative calculation of the test case set's coverage of the terminal's full-condition power consumption. The specific execution process is as follows: First, based on the already constructed full instruction set power consumption model, a full static analysis is performed on the test case set to be verified, breaking down each test case into a corresponding test instruction sequence. Next, based on the full instruction set power consumption model, the cumulative predicted energy consumption, covered power consumption characteristic intervals, and covered instruction opcode types for each hardware unit during the execution of a single test case are calculated. Then, based on the power consumption baseline of the hardware unit, three continuous intervals—low-power condition, rated power condition, and high-power condition—are divided for each hardware unit. The coverage of the test case set across the full operating condition intervals of each hardware unit is statistically analyzed, and the power consumption interval coverage length of a single hardware unit and the overall power consumption coverage of all hardware units in the terminal by the entire test case set are calculated. Finally, the instruction-level power consumption coverage quantification results of the test case set are generated, providing accurate data support for the optimization and completeness verification of the test cases. The test case set to be verified... ,in Let j be the j-th test case, and m be the total number of test cases; test cases Included test instruction sequence k is the total number of instructions contained in this test case; calling the hardware unit test instruction set .

[0029] This module is one of the core application modules of the model, deeply integrating the model with the completeness verification scenario of smart terminal test cases. It solves the pain point of existing technologies that cannot verify the coverage of test cases with the full power consumption of the terminal under all operating conditions. The specific integration method, inputs and outputs, and internal relationships are as follows: Model and scenario integration: This module calls the power consumption model adaptation module to construct a full instruction set instruction-level power consumption prediction model adapted to the current terminal under test for the automated test case set to be verified. Through the inference calculation of the model, the power consumption changes of each hardware unit of the terminal during the execution of the test case are restored, realizing the full instruction-level power consumption coverage quantification of the test case, and providing accurate data support for the optimization and completeness verification of the test case.

[0030] The specific execution process of model application is as follows: This module first performs a full static analysis on the full set of test cases to be verified, splitting each test case into a corresponding sequence of test instructions. Then, the corresponding information of each test instruction is input into the constructed power prediction model. Through the model's inference calculation, the predicted energy consumption data of the corresponding hardware unit when each instruction is executed is obtained. Then, the cumulative predicted energy consumption, the covered power consumption range, and the covered instruction types of each hardware unit during the execution of the entire test case and the entire test case set are statistically obtained. Based on the prediction data output by the model, the quantitative calculation of the power consumption coverage of each hardware unit of the terminal under all operating conditions of the test case set is completed, and finally, the power consumption coverage quantification result of the test case set is generated.

[0031] The intrinsic connection between model input / output and the scenario: The content input to the model in this module is the full execution information of a single instruction obtained by splitting the test cases, which is completely consistent with the input format in the model building stage, ensuring the accuracy of the model inference results; the single instruction-level predicted energy consumption data output by the model directly corresponds to the power consumption changes of the terminal hardware unit during the execution of the test cases, accurately restoring the terminal power consumption conditions that the test cases can cover, fully matching the scenario requirements for test case completeness verification, and realizing a deep integration of the power consumption model and the test case validity verification scenario.

[0032] The power consumption anomaly localization module compares the model with the measured data to complete the instruction-level root cause localization of power consumption anomalies. In this embodiment, it should be noted that the instruction-level root cause localization of power consumption anomalies is based on the full instruction set power consumption model and measured instruction-level energy consumption data. Using the unique timing label of the test instruction as a basis, the measured instruction-level energy consumption data and the predicted energy consumption data are aligned instruction-by-instruction timing to extract a single test instruction. Energy consumption residual data Based on the instruction-hardware unit mapping library, the energy consumption residual data is mapped to the corresponding hardware units. The process involves mapping the driver's call address segment, generating a ranking of hardware unit power consumption anomalies based on their contribution, locating the abnormal hardware unit and its corresponding abnormal instruction set, generating a power consumption anomaly root cause localization report, which includes the opcode of the abnormal instruction, the corresponding hardware unit, the driver address offset, the power consumption residual value, and a unique timing tag. Finally, a single test instruction is obtained. Energy consumption residual Hardware unit Overall energy consumption residual sum of squares Hardware unit Contribution to overall power consumption anomalies ,in For the kth hardware unit The corresponding overall energy consumption residual sum of squares. In detail, during the execution of automated testing tasks, this module completes the collection of measured energy consumption data and the calculation of predicted energy consumption for a single test instruction, and then performs the operation. It covers the entire process of executing all test cases for smart terminals, adapts to power consumption anomaly troubleshooting scenarios at the single instruction level and the single hardware unit level, and completes the alignment of measured and predicted energy consumption data, energy consumption residual calculation, and instruction-level root cause localization of power consumption anomalies. The specific execution process is as follows: First, based on the unique timing tag of the test instruction, the measured instruction-level energy consumption data collected during the automated testing process is precisely aligned with the predicted energy consumption data output by the power consumption model on an instruction-by-instruction basis, and the residual data of the measured energy consumption and predicted energy consumption corresponding to a single test instruction is extracted; then, based on the instruction-hardware unit mapping library built in the previous step, the calculated energy consumption residual data is mapped to the corresponding target hardware unit and driver call address segment; then, based on the residual statistical results, the contribution of each hardware unit to the overall energy consumption deviation is calculated, a ranking of the hardware unit power consumption anomaly contribution is generated, the hardware unit with the highest contribution to the overall power consumption anomaly is located, and the abnormal instruction set corresponding to this hardware unit is identified, and finally a standardized power consumption anomaly root cause localization report is generated. The report includes the opcode of the abnormal instruction, the corresponding hardware unit, the driver address offset, the energy consumption residual value, and the unique timing tag, providing accurate targeted data support for terminal power consumption optimization.

[0033] This module is another core application module of the model, which deeply integrates the model with scenarios such as intelligent terminal power consumption anomaly investigation and root cause localization. It solves the pain point of existing technologies that can only achieve whole-device level power consumption statistics but cannot locate the root cause of power consumption anomalies. The specific integration method, input and output and internal relationship are as follows: Model and scenario integration: This module calls the power consumption prediction model built by the power consumption model adaptation module, and uses the instruction-level predicted energy consumption data output by the model as the benchmark value for judging power consumption anomalies. It compares the data with the actual energy consumption data obtained from actual measurement to achieve instruction-level accurate root cause location of power consumption anomalies, and provides targeted data support for power consumption optimization of smart terminals.

[0034] The specific execution process of model application is as follows: During the execution of automated test cases, this module first uses the unique timing tag of the test instruction to align the energy consumption data of a single instruction obtained by the instruction timing acquisition module with the predicted energy consumption data of the same instruction output by the power consumption prediction model. Then, based on the predicted energy consumption benchmark value output by the model, the deviation between the measured data and the predicted data is calculated to obtain the energy consumption residual data of a single instruction. Subsequently, based on the energy consumption residual data, the overall energy consumption deviation of each hardware unit is statistically analyzed, the contribution of each hardware unit to the overall power consumption anomaly is calculated, and finally the specific hardware unit and specific abnormal instruction that caused the power consumption anomaly are located, generating a standardized root cause localization report.

[0035] The intrinsic connection between model input / output and the scenario: The content input to the model in this module is the full execution information of the actual test instructions, which is completely consistent with the input format in the model building stage, ensuring the accuracy of the prediction benchmark value; the single instruction-level predicted energy consumption data output by the model serves as the sole benchmark for judging whether the power consumption is abnormal during the execution of the instruction, and is directly related to the deviation calculation of the measured data, realizing the accurate location of the root cause from the abnormal power consumption of the whole machine to the single instruction, which fully matches the test scenario requirements of power consumption optimization and anomaly investigation of smart terminals.

[0036] The data traceability and storage module integrates data from the entire process and constructs a traceability system to achieve a closed loop across the entire data chain.

[0037] In this embodiment, it should be noted that: the traceability system is used to integrate the entire process of test data, construct a full-link traceability data structure, and complete the structured association of the entire test process data. The associated data includes firmware image parsing data, instruction-hardware unit mapping data, test instruction timing anchoring data, hardware unit power consumption acquisition data, power consumption model parameter data, test case coverage data, and power consumption anomaly root cause location data. Simultaneously, it is used to generate unique traceability identifiers that are one-to-one bound to the core test elements. The traceability identifier is generated by combining the unique timing tag of the test instruction, the firmware image version number, and the terminal hardware serial number. The data full-link closed loop completes the non-relational timing database storage of the entire link test data and constructs a corresponding data retrieval index. The index fields include firmware version number, hardware unit type, instruction opcode, timing tag, and power consumption anomaly identifier, enabling rapid retrieval and full-link traceability of test data. In detail, this module performs operations synchronously at each stage of the automated testing process. After each stage of operation and data generation is completed, corresponding processing is carried out. It covers the entire testing process data management scenario, from firmware parsing, data acquisition, feature extraction, model building, coverage metric measurement to anomaly localization. It completes the structured association of test data throughout the entire process, generates traceability identifiers, and builds data storage and retrieval indexes, realizing closed-loop management of test data across the entire chain. The specific execution process is as follows: First, a standardized end-to-end traceability data structure is built, incorporating all firmware image parsing data, instruction-hardware unit mapping data, test instruction timing anchoring data, hardware unit power consumption acquisition data, power consumption model parameter data, test case coverage data, and power consumption anomaly root cause location data generated throughout the entire testing process into the structured association scope. A unique traceability identifier is generated for each smallest data unit. This identifier is generated by combining the unique timing tag of the corresponding test instruction, the firmware image version number, and the terminal hardware serial number, achieving a one-to-one binding between the traceability identifier and the core elements of the entire testing process. Finally, the end-to-end test data after structured association is stored in a non-relational timing database. At the same time, a corresponding data retrieval index is built for the stored data. The index fields include firmware version number, hardware unit type, instruction opcode, timing tag, and power consumption anomaly identifier, ultimately achieving rapid retrieval and end-to-end traceability of test data, ensuring the integrity and traceability of the entire testing process data.

[0038] Based on the above scheme and appendix Figure 2 The present invention also provides an automated testing method for smart terminals based on a power consumption model, comprising the following steps: S1. Complete firmware parsing and decoding, and simultaneously establish the instruction-hardware unit mapping basic library; S2, anchor instruction execution timing and synchronously collect instruction-level power consumption data; S3. Based on the collected energy consumption data, extract power consumption characteristics and construct a power consumption baseline. S4. Integrate power consumption characteristic baselines, construct a full instruction set power consumption model, and adapt it for migration; S5. Call the power consumption model to parse test cases and quantify the power consumption coverage under all operating conditions; S6. Compare the model with the measured data to complete the instruction-level root cause localization of power consumption anomalies; S7. Integrate data across the entire process to build a traceability system and achieve a closed loop for the entire data chain.

[0039] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. An automated testing system for intelligent terminals based on a power consumption model, characterized in that, include: Firmware parsing and mapping module: completes firmware parsing and decoding, and establishes the basic library for instruction-hardware unit mapping; Instruction timing acquisition module: anchors instruction execution timing and synchronously acquires instruction-level power consumption data; Power consumption feature construction module: Based on the collected energy consumption data, extract power consumption features and construct a power consumption baseline; Power consumption model adaptation module: integrates power consumption feature baselines, constructs a full instruction set power consumption model, and adapts it for migration; Test case coverage quantization module: calls the power consumption model, parses test cases, and quantifies the power consumption coverage under all operating conditions; Power consumption anomaly localization module: compares the model with the measured data to complete the instruction-level root cause localization of power consumption anomalies; Data traceability and storage module: Integrates data from the entire process and builds a traceability system to achieve a closed loop of the entire data chain.

2. The automated testing system for intelligent terminals based on a power consumption model according to claim 1, characterized in that: The firmware parsing and decoding process is used to perform static unpacking and segmented parsing of the firmware image to be tested on the smart terminal. For encrypted firmware, the firmware memory image running inside the chip is read through the terminal hardware debugging interface to bypass static encryption verification. At the same time, by parsing the segment table information of the firmware, binary segments with executable code segment types and segment names matching driver characteristics are identified. Combined with hardware register mapping addresses, the complete driver binary segment is located and extracted to obtain the instruction set architecture type of the firmware image. Driver binary segment base address Driver binary segment length Based on the extracted instruction set architecture type, a corresponding instruction set decoding rule base is constructed according to the official instruction set architecture manual of that architecture. The mapping relationship between opcode and instruction semantics and hardware call entry is established, and the machine code in the binary segment of the driver is decoded line by line to obtain the opcode, addressing mode, target register and hardware call entry corresponding to each machine instruction. The instruction-hardware unit mapping library is built based on the decoding results, and stores the opcode of each machine instruction and the corresponding subset of hardware units to be called. Driver call address offsets corresponding to each hardware unit This enables the complete binding of a single machine instruction with all associated terminal hardware units.

3. The automated testing system for intelligent terminals based on a power consumption model according to claim 1, characterized in that: The specific method for synchronously acquiring instruction-level power consumption data is as follows: timing anchoring probes are embedded at the entry point of the processor instruction execution queue and the exit point of the write-back stage. The probes are implemented using the hardware breakpoint read-only mechanism of the hardware debugging interface, without modifying instruction data, occupying processor execution clock cycles, or changing the normal execution timing of instructions, and capturing a single test instruction. execution start timestamp With execution end timestamp Simultaneously, a hardware trigger signal for differential transmission is generated based on the captured timestamp. The sampling clock of the external power consumption acquisition device is from the same source as the processor's system clock, with a synchronization accuracy deviation of no more than one sampling clock cycle. This synchronously drives the acquisition device to acquire a single test command. corresponding hardware unit within the execution cycle Real-time power supply voltage With real-time operating current ; and bind a unique timing tag to the collected power consumption data that is consistent with the corresponding test instruction, based on the timestamp of each stage of the pipeline for a single instruction. By determining the time window occupied by the hardware unit and combining the hardware call priority of the instruction with the clock cycle usage ratio, a single test instruction is finally obtained. corresponding hardware unit within the execution cycle instruction-level power consumption This enables precise separation of power consumption data for a single instruction within a superscalar pipeline architecture.

4. The automated testing system for intelligent terminals based on a power consumption model according to claim 1, characterized in that: The power consumption characteristics are based on the collected instruction-level power consumption data, traversing all hardware units corresponding to the test instructions. instruction-level power consumption Extract power consumption characteristic parameters of hardware units, including power consumption benchmark per unit clock cycle. Address offset-related power consumption correction factor The calibration parameters include: idle-state static power consumption; and hardware unit parameter calibration based on clearly defined operating conditions: idle state is defined as a stable operating state with no instruction calls and the clock frequency maintaining the rated minimum value; full-load state is defined as a stable operating state with the clock frequency maintaining the rated maximum value while continuously executing the benchmark test instruction set; the calibration parameters include hardware unit... Static power consumption Minimum static power consumption Peak power consumption Minimum resolution step size of power consumption range The power consumption baseline is constructed based on extracted power consumption feature parameters and is divided into each hardware unit. The static power consumption baseline and dynamic power consumption baseline are determined. The static power consumption baseline is the energy consumption per unit time when the hardware unit is in an idle state without instruction calls, and the dynamic power consumption baseline is the energy consumption change per unit clock cycle when the hardware unit responds to a single instruction call. Finally, the energy consumption benchmark per unit clock cycle is obtained. Energy correction factor related to address offset .

5. The automated testing system for intelligent terminals based on a power consumption model according to claim 4, characterized in that: The full instruction set power consumption model is constructed based on power consumption characteristic parameters and power consumption baseline, combined with the instruction-hardware unit mapping base library and measured instruction-level energy consumption data; it is based on a single test instruction. opcode, target hardware unit, number of clock cycles Driver call address offset As input, output the predicted energy consumption value of the corresponding hardware unit during the execution of this instruction. The adaptation and migration involves designing an automated execution process across terminals and architectures, which includes: extracting core information from the target terminal firmware; extracting power consumption features and constructing a power consumption baseline for the target terminal hardware units; constructing the instruction-hardware unit mapping relationship; adapting and matching model input parameters; generating a power consumption model specific to the target terminal; and characterizing the model prediction accuracy. The predicted energy consumption value... ,in This refers to the actual execution time of a single test instruction I. For instruction-hardware unit mapping indication functions, when the instruction Call hardware unit hour ,otherwise .

6. The automated testing system for intelligent terminals based on a power consumption model according to claim 4, characterized in that: The analytical test cases are based on the constructed full instruction set power consumption model, and a set of test cases to be verified is completed. Full static analysis is performed to break down the data into individual test cases. Included test instruction sequence The full-condition power consumption coverage is based on a full instruction set power consumption model, analyzing each hardware unit during test case execution. The cumulative predicted energy consumption, the covered power consumption characteristic range, and the covered instruction opcode types are used to divide the hardware units. Test case sets are generated from three consecutive intervals: low power consumption, rated power consumption, and high power consumption. The instruction-level power consumption coverage quantization results are used to obtain the hardware unit. power consumption range coverage length and test case set Overall power consumption coverage .

7. The automated testing system for intelligent terminals based on a power consumption model according to claim 1, characterized in that: The instruction-level root cause localization of power consumption anomalies is based on a full instruction set power consumption model and measured instruction-level energy consumption data. Using the unique timing label of each test instruction as a basis, it performs instruction-by-instruction timing alignment between measured and predicted instruction-level energy consumption data, and extracts individual test instructions. Energy consumption residual data Based on the instruction-hardware unit mapping library, the energy consumption residual data is mapped to the corresponding hardware units. The process involves mapping the driver's call address segment, generating a ranking of hardware unit power consumption anomalies based on their contribution, locating the abnormal hardware unit and its corresponding abnormal instruction set, generating a power consumption anomaly root cause localization report, which includes the opcode of the abnormal instruction, the corresponding hardware unit, the driver address offset, the power consumption residual value, and a unique timing tag. Finally, a single test instruction is obtained. Energy consumption residual Hardware unit Overall energy consumption residual sum of squares and hardware units Contribution to overall power consumption anomalies .

8. The automated testing system for intelligent terminals based on a power consumption model according to claim 1, characterized in that: The traceability system integrates end-to-end test data, constructs a full-link traceability data structure, and completes the structured association of test data throughout the entire process. This associated data includes firmware image parsing data, instruction-hardware unit mapping data, test instruction timing anchoring data, hardware unit power consumption acquisition data, power consumption model parameter data, test case coverage data, and power consumption anomaly root cause location data. It also generates unique traceability identifiers that are one-to-one bound to core test elements. These identifiers are generated by combining the unique timing tag of the test instruction, the firmware image version number, and the terminal hardware serial number. This data-wide closed-loop system completes the non-relational timing database storage of end-to-end test data and constructs a corresponding data retrieval index. The index fields include firmware version number, hardware unit type, instruction opcode, timing tag, and power consumption anomaly identifier, enabling rapid retrieval and end-to-end traceability of test data.

9. An automated testing method for intelligent terminals based on a power consumption model, used to implement the automated testing system for intelligent terminals based on a power consumption model as described in any one of claims 1 to 8, characterized in that, include: S1. Complete firmware parsing and decoding, and establish the instruction-hardware unit mapping basic library; S2. Anchor instruction execution timing and synchronously collect instruction-level power consumption data; S3. Based on the collected energy consumption data, extract power consumption characteristics and construct a power consumption baseline. S4. Integrate power consumption characteristic baselines, construct a full instruction set power consumption model, and adapt it for migration; S5. Call the power consumption model to parse test cases and quantify the power consumption coverage under all operating conditions; S6. Compare the model with the measured data to complete the instruction-level root cause localization of power consumption anomalies; S7. Integrate data across the entire process to build a traceability system and achieve a closed loop for the entire data chain.

Images