Battery discharge test method for embedded device and terminal

Abstract

The application provides a battery discharge test method and a terminal of an embedded device, and the method comprises the following steps: collecting platform information of the embedded device, generating a platform feature code based on the platform information, and matching an application program and an automatic test script corresponding to the platform feature code from a preset first mapping relationship; collecting attribute information of a battery carried by the embedded device, generating a battery feature code of the battery based on the attribute information, and matching a battery test strategy corresponding to the battery feature code from a preset second mapping relationship; running the automatic test script in the application program, performing discharge test on the battery, and controlling specific parameters of the discharge test through the battery test strategy. According to the platform feature code, the corresponding test suite is matched, so that the automatic discharge test is realized by using the automatic test script, and according to the battery feature code, the corresponding battery test strategy is matched, so that the safety of the battery test is ensured, and the efficiency of the battery discharge test is improved.

Description

Technical Field

[0001] This invention relates to the field of battery testing, and more particularly to a battery discharge testing method and terminal for embedded devices. Background Technology

[0002] Embedded devices, as the core of modern electronic systems, are widely used in key areas such as consumer electronics, the Internet of Things (IoT), and automotive electronics. With the increasing complexity of device functions, the performance requirements for their battery systems have also significantly increased. The specifications and chemical systems of batteries vary across different platforms and devices, making charge-discharge performance testing (especially "transaction discharge" simulating real-world business loads) a crucial step in ensuring device reliability, safety, and lifespan. Currently, this testing in the industry mainly relies on manual operation, resulting in low efficiency, poor consistency, and high costs. Existing automated testing equipment on the market is mostly limited to a single platform, making it difficult to handle the adaptation and batch testing needs of multiple platforms and battery specifications, which has become a major bottleneck restricting the improvement of product quality and production efficiency. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide a battery discharge testing method and terminal for embedded devices, so as to improve the efficiency of battery discharge testing of embedded devices.

[0004] A battery discharge test method for an embedded device, the method comprising: The platform information of the embedded device is collected, a platform feature code is generated based on the platform information, and the application and automated test script corresponding to the platform feature code are matched from the preset first mapping relationship. Collect the attribute information of the battery carried by the embedded device, generate the battery feature code based on the attribute information, and match the battery test strategy corresponding to the battery feature code from the preset second mapping relationship; The automated test script is run in the application to perform a discharge test on the battery, and the specific parameters of the discharge test are controlled by the battery test strategy.

[0005] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: A terminal includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the various steps of the battery discharge test method for an embedded device.

[0006] The beneficial effects of this invention are as follows: It collects platform information of the embedded device, generates a platform feature code based on the platform information, and matches the application program and automated test script corresponding to the platform feature code from a preset first mapping relationship; it collects attribute information of the battery mounted on the embedded device, generates a battery feature code based on the attribute information, and matches the battery test strategy corresponding to the battery feature code from a preset second mapping relationship; it runs the automated test script in the application program to perform a discharge test on the battery, and controls the specific parameters of the discharge test through the battery test strategy. By using the platform information of the embedded device to generate the platform feature code, the uniqueness of the platform feature code is ensured. By matching the application program and automated test script corresponding to the platform feature code, corresponding application programs and automated test scripts for testing are matched for different embedded devices, thereby realizing automated discharge testing using automated test scripts. Furthermore, by using the battery attribute information to generate the battery feature code and matching the battery test strategy corresponding to the battery feature code, different test strategies are set for batteries with different attributes. By controlling the battery discharge test process through the test strategy, the safety of battery testing is ensured, and the efficiency of battery discharge testing of embedded devices is improved. Attached Figure Description

[0007] Figure 1 This is a flowchart of a battery discharge test method for an embedded device according to an embodiment of the present invention; Figure 2 This is another flowchart of the battery discharge test method for an embedded device according to an embodiment of the present invention; Figure 3 This is a graph showing the power consumption per 100 transactions for the battery discharge test method of the embedded device according to an embodiment of the present invention. Figure 4 This is a transaction curve of 10% battery capacity for the battery discharge test method of the embedded device according to an embodiment of the present invention. Figure 5 This is an architecture diagram of the battery discharge test system for an embedded device according to an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of the battery discharge test terminal of the embedded device according to an embodiment of the present invention; Label Explanation: 1. A battery discharge test terminal for an embedded device; 2. A memory; 3. A processor. Detailed Implementation

[0008] In related technologies, embedded devices, as core components of modern electronic systems, are widely used in consumer electronics, industrial control, automotive electronics, and the Internet of Things (IoT). With the rapid evolution of technology, the functions of embedded devices are becoming increasingly complex, and their integration level is constantly improving, which places higher demands on their battery systems. Embedded devices of different platforms and models often need to be compatible with batteries of various specifications and chemical systems (such as lithium-ion, lithium polymer, and nickel-metal hydride). The charge-discharge performance of the battery, including capacity, cycle life, internal resistance, and safety characteristics, directly affects the overall reliability, operational safety, and lifespan of the device.

[0009] Currently, the industry still primarily relies on traditional manual methods for charging and discharging batteries in embedded devices. Testers must manually connect the battery to the testing equipment, set the relevant parameters, and record the test data. This method is not only inefficient and unsuitable for mass production scenarios, but also prone to inconsistent test results due to human error, affecting the accuracy of product quality assessment. Furthermore, manual testing is costly and carries certain safety risks, especially when testing high-energy-density batteries.

[0010] Although some automated battery testing equipment has emerged in the market, its functionality is usually limited to a single platform or specific battery type, lacking flexibility and versatility. In the context of parallel development and production of multi-platform embedded devices, existing testing solutions struggle to achieve rapid switching and adaptation, failing to meet enterprises' needs for efficient and unified testing of batteries of various specifications and systems.

[0011] Therefore, there is an urgent need to develop an automated testing system for batteries in embedded devices across multiple platforms, in order to improve testing efficiency and consistency, reduce testing costs, and ensure the safety and reliability of the testing process.

[0012] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0013] A battery discharge test method for embedded devices, please refer to Figure 1 as well as Figure 2 This includes steps S110 to S130.

[0014] S110. Collect platform information of the embedded device, generate a platform feature code based on the platform information, and match the application and automated test script corresponding to the platform feature code from a preset first mapping relationship. For example, a manufacturer has device A (Qualcomm SDM660, Android 10) and device B (MediaTek MT6762, Android 11). Device A generates the feature code A920_10_SDM660_8_PROJ2024A, and the system automatically matches and loads the application and automated test script optimized for the "Qualcomm + Android 10" environment. Device B generates the feature code X900_11_MT6762_12_PROJ2024B, and the system automatically matches and loads the application and automated test script optimized for the "MTK + Android 11" environment.

[0015] S120. Collect the attribute information of the battery mounted on the embedded device, generate the battery feature code based on the attribute information, and match the battery test strategy corresponding to the battery feature code from a preset second mapping relationship. For example, for the same model of device A, a Brand A lithium-ion battery (3000mAh) is used in project A, and a Brand B lithium iron phosphate battery (2000mAh) is used in project B.

[0016] For the device in Project A, the platform signature is A920_10_SDM660_8_PROJ2024A, and the battery signature is BrandA_Li-ion_3000mAh. The system matching strategy is: low battery threshold of 15%, sampling frequency of 10Hz, 2 retries, and the test terminates when the total number of transactions reaches 1000 or the test process accumulates 50 failures. For the device in Project B, the platform signature is A920_10_SDM660_5_PROJ2024B, and the battery signature is BrandB_LFP_2000mAh. The system matching strategy is: low battery threshold of 20%, sampling frequency of 100Hz, 5 retries, and the test terminates when the total number of transactions reaches 700 or the test process accumulates 50 failures.

[0017] S130. The automated test script is run in the application to perform a discharge test on the battery, and the specific parameters of the discharge test are controlled by the battery test strategy. In some embodiments, the system first configures the device hardware status, such as turning on Bluetooth, Wi-Fi, and mobile network, and checks the status of peripherals (such as printers) to simulate a real high-power working scenario. Subsequently, the application is installed and launched via ADB commands, for example, by launching a dedicated application via the command line `adb install -r / path / to / A920_10_SDM660_8_PROJ2024A.apk`. In the launched application, the matched automated test script is run, for example, by executing the automated test script via the command line `adb shell monkey -f / mnt / sdcard / inputpassw.txt -v 50`. This script simulates a complete business process, such as "enter amount - swipe card - enter password - print voucher". Throughout the test, the system strictly controls the specific parameters of the discharge test in real time according to the loaded battery test strategy. The test is terminated when the battery level falls below a set value based on the low battery alarm threshold. Based on the maximum timeout threshold and retry strategy for a single test, manage the timeout and retry logic for that test. Dynamically adjust the sampling rate of the data acquisition module based on the current sampling parameters. Monitor the overall test status based on the test termination conditions, and safely terminate the entire test process when the preset target is reached or an anomaly occurs.

[0018] As described above, the beneficial effects of this invention are as follows: By collecting platform information of embedded devices, generating platform feature codes based on the platform information, and matching the application program and automated test script corresponding to the platform feature code from a preset first mapping relationship, for the same test system, no manual configuration changes are required. By using the generated platform feature code to match the corresponding application program and automated test script, multiple completely different hardware platforms can be automatically identified and adapted. This can meet the testing needs of multi-platform embedded devices and correctly execute the test process, solving the adaptation problem of batch testing of multi-platform devices. By collecting the attribute information of the battery carried by the embedded device, generating the battery feature code based on the attribute information, and matching the battery test strategy corresponding to the battery feature code from a preset second mapping relationship, even though the device hardware platform is the same, the system accurately distinguishes different batteries through project number and battery feature code, and applies completely differentiated, optimal, and safe test strategies to batteries with different chemical systems and capacities. This achieves good adaptability and refined testing level even in complex mixed production scenarios. By running automated test scripts in the application, the battery is discharged and tested. The specific parameters of the discharge test are controlled by the battery test strategy. From environment preparation, application startup, script execution to data acquisition, the entire process requires no manual intervention. The test strategy controls each stage of the test in real time, making the test process both efficient and safe.

[0019] Further, step S110 includes steps S111 to S112.

[0020] S111. Collect platform information of the embedded device, including device product model, operating system version, CPU model, number of driver compatibility identifiers, and project number. In some embodiments, key platform information of the device is automatically collected through the device command interface when the system starts. For example, the device product model is obtained through the command line `adb shell getpropro.product.model`. The operating system version is obtained through the command line `adb shell getpropro.build.version.release`. The CPU model is obtained through the command line `adb shell cat / proc / cpuinfo`. The number of driver compatibility identifiers is obtained through the command line `adb shell ls / system / lib / modules / |wc -l`. The project number is obtained either through the system graphical interface for user selection or automatically based on a configuration file.

[0021] S112. A platform feature code is generated by combining the device product model, operating system version, CPU model, number of driver compatibility identifiers, and project number using a preset first separator. In some embodiments, the five dimensions of information—device product model, operating system version, CPU model, number of driver compatibility identifiers, and project number—are combined in a fixed order using a preset first separator (as in the underscore "_"). For example, if the device product model is A920, the operating system version is 10, the CPU model is SDM660, the number of driver compatibility identifiers is 8, and the project number is PROJ2024A, the corresponding generated platform feature code is A920_10_SDM660_8_PROJ2024A.

[0022] As described above, by collecting platform information of embedded devices, including device product model, operating system version, central processing unit model, number of driver compatibility identifiers and project number, and using a preset first separator, the device product model, operating system version, central processing unit model, number of driver compatibility identifiers and project number are combined to generate a platform feature code to ensure the uniqueness of the platform feature code.

[0023] Further, before matching the application and automated test script corresponding to the platform feature code from the preset first mapping relationship, the step includes: using the platform feature code as the key in a key-value pair, and using the application and automated test script corresponding to the platform feature code as the value in the key-value pair, to form the key-value pair as the first mapping relationship. In some embodiments, the first mapping relationship is a device transaction feature mapping table of a preset use case library platform (such as a battery-specific test case library). The system uses the generated platform feature code as the query key to perform an exact match in the mapping table. If the match is successful, the system returns the installation package path of the transaction application customized for that platform and the path of the automated test script; if the match is not successful, the system returns a general default application and script to ensure that the testing process can continue.

[0024] As described above, by using the platform signature as the key and the corresponding application and automated test script as the value in key-value pairs, a primary mapping relationship is formed. Through precise matching of platform signatures, the system can automatically load dedicated test drivers (applications) and operation scripts for devices with different hardware, operating system versions, and projects. The system can match and load different APKs and scripts separately, eliminating the need for tedious manual environment configuration and greatly improving test preparation efficiency. Furthermore, using dedicated applications and scripts avoids software incompatibility, functional abnormalities, or test logic errors caused by platform differences, ensuring consistency in the testing process and comparability of results from the source.

[0025] Further, step S120 includes steps S121 to S122.

[0026] S121. Collect the attribute information of the battery mounted on the embedded device. The attribute information includes manufacturer information, chemical type, and design capacity. In some embodiments, the battery attribute information is read through the battery management interface of the device system (such as a node under / sys / class / power_supply / battery / ). For example, the manufacturer information is Brand A, the chemical type is "Li-ion" (lithium-ion) or "LFP" (lithium iron phosphate), and the design capacity is 3000mAh.

[0027] S122. A battery feature code is generated by combining the manufacturer information, the chemical type, and the design capacity using a preset second separator. In some embodiments, the attribute information is combined using a preset second separator (as in the underscore "_"). The second separator may be the same as or different from the first separator. For example, the generated battery feature code is: BrandA_Li-ion_3000mAh.

[0028] As described above, by collecting the attribute information of the battery carried by the embedded device, including manufacturer information, chemical type and design capacity, the manufacturer information, chemical type and design capacity are combined using a preset second separator to generate a battery feature code, so as to ensure the uniqueness of the battery feature code.

[0029] Further, the step of matching the battery test strategy corresponding to the battery feature code from the preset second mapping relationship includes: matching the low battery alarm threshold corresponding to the battery feature code from the preset second mapping relationship; the step of controlling the discharge test process through the battery test strategy includes: acquiring the low battery alarm threshold, and pausing or terminating the discharge test when the real-time collected battery level is less than or equal to the low battery alarm threshold. In some embodiments, the system automatically sets a reasonable low battery alarm threshold according to different brands or types of batteries, since the effective discharge cutoff voltage of the batteries is different. For example, a threshold of 15% is matched for lithium-ion batteries (Li-ion), and a threshold of 20% is matched for lithium iron phosphate batteries (LFP). During the discharge test, when the real-time collected battery level is less than or equal to this threshold, the system will automatically pause or terminate the test.

[0030] As described above, the low power alarm threshold corresponding to the battery feature code is matched from the preset second mapping relationship to obtain the low power alarm threshold. When the real-time collected power is less than or equal to the low power alarm threshold, the discharge test is paused or terminated. By setting different low power alarm thresholds for different brands or types of batteries, the test is automatically paused or terminated to prevent the battery from being damaged due to over-discharge.

[0031] Furthermore, the step of matching the battery test strategy corresponding to the battery feature code from the preset second mapping relationship further includes: matching the maximum single test time threshold and the test failure retry strategy corresponding to the battery feature code from the preset second mapping relationship; the step of controlling the discharge test process through the battery test strategy further includes: determining that the discharge test is an abnormal discharge test when the discharge test time exceeds the maximum single test time threshold or the test fails and triggers a retry, based on the maximum single test time threshold and the test failure retry strategy. In some embodiments, the maximum single test time threshold is the maximum allowed time for a set single test process; if the timeout occurs, it is determined as a test failure and a retry operation is triggered. The test failure retry strategy sets different maximum number of retryes and retry intervals for batteries with different stability (such as those related to internal resistance and aging degree). For example, a timeout threshold of 50 seconds and a maximum of 2 retries are set for new batteries; an timeout threshold of 80 seconds and a maximum of 5 retries are set for older batteries with potentially poor stability. When a single test takes longer than the threshold or the transaction fails, the system triggers a retry according to the strategy and marks the test as "abnormal".

[0032] As described above, the system matches the maximum single-test time threshold and test failure retry strategy corresponding to the battery feature code from the preset second mapping relationship. Based on the maximum single-test time threshold and the test failure retry strategy, when the discharge test time exceeds the maximum single-test time threshold or the test fails and triggers a retry, the discharge test is determined to be an abnormal discharge test. By preset differentiated "maximum single-test time threshold" and "retry strategy" for different types of batteries (such as new batteries and aged batteries), the system can intelligently tolerate and handle occasional anomalies or delays that occur during the test. This avoids unnecessary test interruptions caused by occasional factors such as short-term communication delays, instantaneous system load, or small fluctuations in the battery itself, ensuring that the test task can continue to advance within the allowable elasticity range, thereby improving the completion rate and overall efficiency of long-cycle and batch tests.

[0033] Furthermore, the step of matching the battery test strategy corresponding to the battery feature code from the preset second mapping relationship further includes: matching the current sampling parameters corresponding to the battery feature code from the preset second mapping relationship; the step of controlling the discharge test process through the battery test strategy further includes: controlling the sampling rate of the analog-to-digital converter of the embedded device according to the current sampling parameters. In some embodiments, the sampling parameters of the data acquisition module (such as the analog-to-digital converter) are dynamically adjusted according to the battery's design capacity. For example, a sampling frequency of 10Hz is matched for a large-capacity battery of 3000mAh, and a sampling frequency of 100Hz is matched for a small-capacity battery of 2000mAh.

[0034] As described above, the current sampling parameters corresponding to the battery feature code are matched from the preset second mapping relationship. Based on the current sampling parameters, the sampling rate of the analog-to-digital converter of the embedded device is controlled. The high frequency is used to capture the subtle fluctuations of small batteries, and the low frequency is used to optimize the resource consumption of large battery testing, thereby realizing the dynamic optimization of data acquisition density.

[0035] Furthermore, the step of matching the battery test strategy corresponding to the battery feature code from the preset second mapping relationship further includes: matching the test termination condition corresponding to the battery feature code from the preset second mapping relationship; controlling the discharge test process through the battery test strategy further includes: stopping the discharge test process when at least one of the following conditions is met: a preset total number of tests, a preset number of consecutive test failures, and a battery voltage drop rate exceeding a safety threshold, according to the test termination condition. In some embodiments, the test termination condition defines a global stop rule for the entire automated test cycle. In addition to the preset total number of tests (e.g., 1000), it also includes conditions such as "N consecutive test failures" (e.g., 50 consecutive failures) or "battery voltage drop rate exceeding a safety threshold" (e.g., a drop of more than 10% per minute).

[0036] As described above, the test termination condition corresponding to the battery feature code is matched from the preset second mapping relationship. Based on the test termination condition, the discharge test process is stopped when at least one of the preset total number of tests, preset number of consecutive test failures, and battery voltage drop rate exceeds a safety threshold is met, so as to protect battery safety and test equipment.

[0037] Furthermore, the battery discharge test method for the embedded device further includes steps H110 to H120.

[0038] H110. During the discharge test of the battery, the test data of the battery is collected in real time. In some embodiments, during the discharge test, the system collects the test data of the battery in real time, including voltage, current, percentage of charge, number of tests, etc. For example, Table 1 shows the power consumption data per 100 transactions of the battery discharge test method for the embedded device according to an embodiment of the present invention, and Table 2 shows the transaction data per 10% of the charge of the battery discharge test method for the embedded device according to an embodiment of the present invention.

[0039] Table 1

[0040] Table 2

[0041] H120. Based on the test data, generate a battery discharge performance analysis report. In some embodiments, after the test, the system generates a battery discharge performance analysis report based on the test data. The report may include core curves such as the "power consumption curve per 100 transactions" and the "number of transactions that can be completed per 10% of battery capacity" curve, intuitively reflecting the battery's discharge performance and stability at different stages. For example, Figure 3 To illustrate the power consumption curve per 100 transactions for the battery discharge test method of the embedded device according to an embodiment of the present invention, the graph shows the trend of power consumption during the test. Figure 4 The diagram illustrates the transaction curve for each 10% of battery charge in the battery discharge test method for an embedded device according to an embodiment of the present invention, reflecting the number of transactions that can be executed at different battery levels.

[0042] As described above, by collecting the battery's test data in real time during the battery discharge test, and generating a battery discharge performance analysis report based on the test data, the automated data collection and analysis generates a test report in a unified format that includes key performance curves. This provides an objective and quantitative basis for battery performance evaluation, quality comparison, and problem diagnosis, greatly improving the efficiency and level of quality control.

[0043] According to another aspect of the invention, please refer to Figure 5An embedded device battery discharge testing system 100 includes the interaction between a platform feature code parsing module (110), a battery feature information recognition module (120), a transaction process execution module (130), and a data acquisition and analysis module (140). The platform feature code parsing module (110) is responsible for collecting the device product model, operating system version, central processing unit model, number of driver compatibility identifiers, and project number as the platform feature code; the battery feature information recognition module (120) is used to detect battery capacity specifications and manufacturer information for dynamic parameter configuration; the transaction process execution module (130) matches the power consumption mode to start an automated test script simulating a transaction scenario; and the data acquisition and analysis module (140) is responsible for real-time acquisition of test data and generation of discharge curves.

[0044] According to another aspect of the invention, please refer to Figure 6 A battery discharge test terminal 1 for an embedded device includes a memory 2, a processor 3, and a computer program stored on the memory 2 and running on the processor 3. When the processor 3 executes the computer program, it implements the various steps in the above-mentioned battery discharge test method for an embedded device.

[0045] In summary, the present invention provides a method to collect platform information of embedded devices, generate platform feature codes based on the platform information, and match the corresponding application and automated test scripts from a preset first mapping relationship. For the same test system, no manual configuration changes are required. By using the generated platform feature codes to match the corresponding application and automated test scripts, it can automatically identify and adapt to multiple completely different hardware platforms, meet the testing needs of multi-platform embedded devices, and correctly execute the test process, thus solving the adaptation problem of batch testing of multi-platform devices. By collecting the attribute information of the battery carried by the embedded device, generating the battery feature code based on the attribute information, and matching the corresponding battery test strategy from a preset second mapping relationship, even though the device hardware platform is the same, the system accurately distinguishes different batteries through project number and battery feature code, and applies completely differentiated, optimal, and safe test strategies to batteries with different chemical systems and capacities. This achieves good adaptability and refined testing level even in complex mixed production scenarios. By running automated test scripts within the application, battery discharge tests are performed. Specific parameters of the discharge test are controlled through battery testing strategies. From environment preparation, application startup, script execution to data acquisition, the entire process requires no manual intervention. The test strategy regulates each stage of the test in real time, making the testing process both efficient and safe. During the battery discharge test, test data is collected in real time. Based on this data, a battery discharge performance analysis report is generated. Automated data acquisition and analysis produce a standardized test report containing key performance curves, providing objective and quantitative evidence for battery performance evaluation, quality comparison, and problem diagnosis, significantly improving the efficiency and level of quality control.

[0046] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A battery discharge test method for an embedded device, characterized in that, include: The platform information of the embedded device is collected, a platform feature code is generated based on the platform information, and the application and automated test script corresponding to the platform feature code are matched from the preset first mapping relationship. Collect the attribute information of the battery carried by the embedded device, generate the battery feature code of the battery based on the attribute information, and match the battery test strategy corresponding to the battery feature code from the preset second mapping relationship; The automated test script is run in the application to perform a discharge test on the battery, and the specific parameters of the discharge test are controlled by the battery test strategy.

2. The battery discharge test method for embedded devices according to claim 1, characterized in that, The process of collecting platform information from embedded devices and generating platform feature codes based on that platform information includes: The platform information of the embedded device is collected, including the device product model, operating system version, central processing unit model, number of driver compatibility identifiers, and project number. The platform feature code is generated by combining the device product model, the operating system version, the central processing unit model, the number of driver compatibility identifiers, and the project number using a preset first separator.

3. The battery discharge test method for embedded devices according to claim 1, characterized in that, Before matching the application and automated test script corresponding to the platform feature code from the preset first mapping relationship, the process includes: The platform feature code is used as the key in the key-value pair, and the application and automated test script corresponding to the platform feature code are used as the values ​​in the key-value pair to form the first mapping relationship.

4. The battery discharge test method for embedded devices according to claim 1, characterized in that, The step of collecting attribute information of the battery mounted on the embedded device and generating a battery feature code based on the attribute information includes: Collect the attribute information of the battery carried by the embedded device, including manufacturer information, chemical type and design capacity; Using a preset second separator, the manufacturer information, the chemical type, and the design capacity will be combined to generate a battery feature code.

5. The battery discharge test method for embedded devices according to claim 1, characterized in that, The battery testing strategy for matching the battery feature code from the preset second mapping relationship includes: Match the low battery alarm threshold corresponding to the battery feature code from the preset second mapping relationship; The control of the discharge test process through the battery test strategy includes: Obtain the low battery alarm threshold. When the real-time collected battery level is less than or equal to the low battery alarm threshold, pause or terminate the discharge test.

6. The battery discharge test method for embedded devices according to claim 1, characterized in that, The battery testing strategy for matching the battery feature code from the preset second mapping relationship further includes: Match the maximum single test time threshold and test failure retry strategy corresponding to the battery feature code from the preset second mapping relationship; The method of controlling the discharge test process through the battery test strategy also includes: Based on the maximum time threshold for a single test and the test failure retry strategy, when the time taken for the discharge test exceeds the maximum time threshold for a single test or the test failure triggers the test failure retry strategy, the discharge test is determined to be an abnormal discharge test.

7. The battery discharge test method for embedded devices according to claim 1, characterized in that, The battery testing strategy for matching the battery feature code from the preset second mapping relationship further includes: Match the current sampling parameters corresponding to the battery feature code from the preset second mapping relationship; The method of controlling the discharge test process through the battery test strategy also includes: The sampling rate of the analog-to-digital converter in the embedded device is controlled based on the current sampling parameters.

8. The battery discharge test method for embedded devices according to claim 1, characterized in that, The battery testing strategy for matching the battery feature code from the preset second mapping relationship further includes: Match the test termination condition corresponding to the battery feature code from the preset second mapping relationship; The method of controlling the discharge test process through the battery test strategy also includes: According to the test termination conditions, the discharge test process is stopped when at least one of the following conditions is met: the total number of preset tests, the number of preset consecutive test failures, and the battery voltage drop rate exceeds a safety threshold.

9. The battery discharge test method for embedded devices according to claim 1, characterized in that, Also includes: During the discharge test of the battery, the test data of the battery is collected in real time; Based on the test data, a battery discharge performance analysis report is generated.

10. A battery discharge test terminal for an embedded device, characterized in that, The device includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the battery discharge test method of any one of claims 1 to 9 for the embedded device.

Images