Vehicle-mounted peripheral stability testing method, medium and vehicle

Abstract

The invention belongs to the technical field of vehicle control, and particularly provides a vehicle-mounted peripheral stability test method, a medium and a vehicle, and the method comprises the steps: obtaining target identification information in a vehicle-mounted system, and positioning a to-be-tested target external device based on the target identification information; starting an automatic loop test for the target external equipment, wherein the automatic loop test comprises alternately executing equipment mounting operation and equipment unloading operation; monitoring the running state of the target external equipment and the resource state of the vehicle-mounted system in real time in the automatic cycle test process; and generating a test log based on the running state and the resource state, and determining a stability evaluation result of the target external equipment according to the test log. Through the technical scheme provided by the invention, the stability testing efficiency of the vehicle-mounted peripheral can be improved.

Description

Technical Field

[0001] This application belongs to the field of vehicle control technology, and in particular relates to a test method, medium and vehicle for the stability of vehicle peripherals. Background Technology

[0002] In automotive system applications, the stability of external devices such as USB flash drives and SD cards is directly related to user experience and system security. Stability testing is a key part of automotive device development. However, in existing technologies, there are often problems such as difficulty in reproducing complex automotive operating conditions and potential conflicts between testing and the core functions of the automotive system. Manual testing or simple simulation testing is inefficient. Therefore, how to improve the efficiency of stability testing for automotive peripherals is an urgent technical problem to be solved. Summary of the Invention

[0003] The embodiments of this application provide a method, apparatus, program product, medium, and vehicle for testing the stability of vehicle peripherals, thereby improving the efficiency of vehicle peripheral stability testing.

[0004] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0005] According to a first aspect of the embodiments of this application, a method for testing the stability of an in-vehicle peripheral device is provided, characterized in that the method includes: acquiring target identification information in an in-vehicle system and locating a target external device to be tested based on the target identification information; initiating an automated cyclic test for the target external device, the automated cyclic test including alternately executing device mounting and device unmounting operations; during the automated cyclic test, monitoring the operating status of the target external device and the resource status of the in-vehicle system in real time; generating a test log based on the operating status and the resource status, and determining the stability evaluation result of the target external device based on the test log.

[0006] In some embodiments of this application, based on the aforementioned scheme, the step of obtaining target identification information from the vehicle system and locating the target external device to be tested based on the target identification information includes: reading the mounting record file of the vehicle system, the mounting record file containing path information and mounting point information of all mounted devices; filtering out the path information and mounting point information corresponding to non-vehicle system built-in devices from the mounting record file as target identification information; and determining the external device corresponding to the target identification information as the target external device.

[0007] In some embodiments of this application, based on the previous scheme, initiating an automated cyclic test for the target external device includes: obtaining cyclic parameters for the automated cyclic test, the cyclic parameters including the total number of tests and the duration of a single mount / unmount interval; and performing the device mount operation and the device unmount operation based on the cyclic parameters, wherein the device mount operation is to mount the target external device to a preset mount point, and the device unmount operation is to unmount the target external device from the preset mount point.

[0008] In some embodiments of this application, the loop parameter further includes a test mode identifier, which includes a daily commuting mode, a long-distance driving mode, or a high-frequency plug-in / unplug mode. When the test mode identifier is a daily commuting mode, the total number of tests is set to the first number, and the single loading / unloading interval is set to the first duration. When the test mode identifier is a long-distance driving mode, the total number of tests is set to the second number, and the single loading / unloading interval is set to the second duration, wherein the second number is less than the first number, and the second duration is greater than the first duration. When the test mode identifier is a high-frequency plug-in / unplug mode, the total number of tests is set to the third number, and the single loading / unloading interval is set to the third duration, wherein the third number is greater than the first number, and the third duration is less than the first duration.

[0009] In some embodiments of this application, based on the foregoing scheme, the real-time monitoring of the operating status of the target external device and the resource status of the vehicle system includes: monitoring the mounting validity of the target external device after the device mounting operation, wherein the mounting validity includes whether the target file exists at the preset mounting point and whether file reading and writing are normal; monitoring the unloading validity of the target external device after the device unloading operation, wherein the unloading validity includes whether the preset mounting point is empty and whether the device occupancy status is released; and monitoring the resource status of the vehicle system, wherein the resource status includes the number of file descriptors, the storage management service process status, and the CPU and memory usage rate.

[0010] In some embodiments of this application, based on the foregoing scheme, the method further includes: during the automated loop test, counting the cumulative number of abnormal running states, the abnormal running states including invalid mounting or invalid unmounting; when the cumulative number reaches a preset error threshold, terminating the automated loop test, and recording the termination reason in the test log.

[0011] In some embodiments of this application, based on the foregoing scheme, the method further includes: acquiring environmental simulation parameters of the vehicle system, the environmental simulation parameters including vibration frequency, temperature range and electromagnetic interference intensity; controlling an environmental simulation device to apply corresponding environmental influences to the target external device based on the environmental simulation parameters; and performing the automated cyclic test step during the continuous process of the environmental influences.

[0012] In some embodiments of this application, based on the foregoing scheme, the method further includes: when the vehicle system is connected to multiple external devices, allocating an independent test process for each external device; controlling each test process to execute the automated cyclic test in parallel, and distinguishing and recording the test data of each external device in the test log.

[0013] According to a second aspect of the embodiments of this application, a testing device for the stability of vehicle peripherals is provided, characterized in that the device comprises: an acquisition unit, configured to acquire target identification information in a vehicle system and locate a target external device to be tested based on the target identification information; a testing unit, configured to initiate an automated cyclic test for the target external device, the automated cyclic test including alternating execution of device mounting and device unmounting operations; a monitoring unit, configured to monitor the operating status of the target external device and the resource status of the vehicle system in real time during the automated cyclic test; and an evaluation unit, configured to generate a test log based on the operating status and the resource status, and determine the stability evaluation result of the target external device based on the test log.

[0014] According to a third aspect of the embodiments of this application, a computer program product is provided, the computer program product including computer instructions stored in a computer-readable storage medium and adapted to be read and executed by a processor to cause a computer device having the processor to perform an operation as described in any of the embodiments of the first aspect above.

[0015] According to a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided, the computer-readable storage medium storing at least one computer program instruction, the at least one computer program instruction being loaded and executed by a processor to perform the operation performed by the method described in any of the embodiments of the first aspect above.

[0016] According to a fifth aspect of the present application, a vehicle is provided, the vehicle including one or more processors and one or more memories, the one or more memories storing at least one computer program instruction, the at least one computer program instruction being loaded and executed by the one or more processors to perform the operation as described in any of the embodiments of the first aspect above.

[0017] Based on the technical solution proposed in this application, the target external device to be tested can be accurately identified by acquiring target recognition information from the vehicle system, avoiding confusion between peripherals and vehicle internals, and improving the targeting and efficiency of testing. By automatically and alternately executing device loading and unloading operations, high-frequency and long-term testing can be achieved without manual intervention. This can simulate the real working conditions of users frequently plugging and unplugging peripherals, efficiently capture occasional anomalies, and promptly locate potential stability hazards in the dynamic connection process of the device. By synchronously monitoring the operating status of the target external device and the resource status of the vehicle system in real time, both the stability of the device itself and its impact on the system can be taken into account, ensuring the comprehensiveness of the stability assessment. The test log generated based on the monitoring data and the evaluation results determined accordingly can avoid subjective judgment bias. At the same time, the log can trace the specific working conditions under which the anomaly occurred, providing clear data basis for subsequent device defect investigation and vehicle system compatibility optimization, thereby improving the accuracy and efficiency of vehicle peripheral testing.

[0018] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings: Figure 1 A flowchart illustrating a method for testing the stability of vehicle peripherals in one embodiment of this application is shown; Figure 2 A detailed flowchart of a method for testing the stability of vehicle peripherals in one embodiment of this application is shown; Figure 3 A block diagram of a testing apparatus for the stability of vehicle peripherals according to one embodiment of this application is shown; Figure 4 A schematic diagram of the vehicle structure in one embodiment of this application is shown. Detailed Implementation

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

[0021] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0022] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0023] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0024] It should also be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such uses of these terms can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described.

[0025] In in-vehicle system applications, the stability of external devices such as USB flash drives and SD cards is directly related to user experience and system security. Stability testing is a key part of the development of in-vehicle devices. However, in existing technologies, there are often problems such as difficulty in reproducing complex in-vehicle operating conditions and the test being prone to conflict with the core functions of the in-vehicle system. Manual testing or simple simulation testing is inefficient. Therefore, this application proposes a testing method for the stability of in-vehicle peripherals to improve the efficiency of stability testing for in-vehicle peripherals.

[0026] Next, we will combine Figure 1 The test method for the stability of vehicle peripherals proposed in this application is described in detail.

[0027] See Figure 1 A flowchart illustrating a method for testing the stability of vehicle peripherals in one embodiment of this application is shown, as follows: Figure 1 As shown, the method may include at least the following steps 110 to 140: Step 110: Obtain target recognition information from the vehicle system and locate the target external device to be tested based on the target recognition information.

[0028] Step 120: Initiate an automated loop test for the target external device, the automated loop test including alternating execution of device mounting and device unmounting operations.

[0029] Step 130: During the automated cyclic test, the operating status of the target external device and the resource status of the vehicle system are monitored in real time.

[0030] Step 140: Generate test logs based on the running status and the resource status, and determine the stability assessment result of the target external device based on the test logs.

[0031] In this application, the external device may specifically include a USB flash drive, SD card, portable hard drive, microphone, game controller, etc., and may also be other devices as needed. This application does not make any specific limitations on this.

[0032] In this application, the location of the target external device to be tested based on the target identification information can specifically be achieved by parsing the / proc / mounts system file to automatically identify the partition path and mount point of the external device, excluding the system's built-in storage. This application does not impose any specific limitations on this.

[0033] In this application, the target external device to be tested is located based on the target identification information. The target identification information in the vehicle system can be used to lock the device to be tested, ensuring the accuracy of the test object and avoiding confusion between the vehicle's built-in devices and external devices. This allows for the accurate selection of external devices that need to be tested for stability, improving the accuracy and efficiency of the test.

[0034] In this application, by initiating an automated cyclic test for the target external device, the connection and disconnection scenarios in actual use of the external device can be simulated, thereby enabling continuous testing without human intervention. This test process does not require manual operation and is automatically triggered by the vehicle system or supporting test module, which can effectively improve the efficiency of vehicle peripheral testing.

[0035] In this application, the device mounting operation refers to the vehicle system establishing a connection with the target external device, enabling the device to successfully connect to the system and have normal functional output capabilities. The device unmounting operation refers to the vehicle system disconnecting from the target external device, releasing the device from its connected state. Alternating execution means repeatedly cycling through the sequence of mounting → unmounting → remounting → remounting. The number of cycles or the duration can be set according to testing requirements to fully simulate the actual usage scenario of users repeatedly plugging and unplugging devices and switching connection states. In this application, by monitoring the operating status of the target external device and the resource status of the vehicle system in real time during automated cyclic testing, it is possible to comprehensively capture the device and system status during the testing process, promptly detect potential anomalies, and generate test logs to systematically record the real-time monitored data. This transforms the abstract concept of "stability" into quantifiable and traceable concrete data. The device stability is then judged based on the log data. For example, if mounting or unmounting is successful in 1000 cyclic tests, the device shows no abnormalities, and system resources remain within the normal range, it indicates excellent device stability. Conversely, if multiple mounting failures, device crashes, or persistently high system CPU usage occur, it indicates a defect in device stability.

[0036] In this application, by obtaining target recognition information from the vehicle system, the target external device to be tested can be accurately identified, avoiding confusion between peripherals and vehicle internals, thus improving the targeting and efficiency of testing. Through automated, cyclical alternation of device loading and unloading operations, high-frequency, long-term testing can be achieved without manual intervention. This simulates the real-world working conditions of users frequently plugging and unplugging peripherals, efficiently capturing occasional anomalies, and promptly locating potential stability issues during dynamic device connections. By synchronously monitoring the operating status of the target external device and the resource status of the vehicle system in real time, both the device's own stability and its impact on the system can be considered, ensuring a comprehensive stability assessment. Generating test logs based on monitoring data and determining the assessment results accordingly avoids subjective judgment bias. Furthermore, the logs can trace the specific operating conditions under which anomalies occurred, providing clear data for subsequent device defect investigation and vehicle system compatibility optimization, thereby improving the accuracy and efficiency of vehicle peripheral testing.

[0037] In step 110 above, the step of acquiring target recognition information from the vehicle system and locating the target external device to be tested based on the target recognition information can be specifically performed according to steps 111 to 113 as follows: Step 111: Read the mounting record file of the vehicle system. The mounting record file contains path information and mounting point information of all mounted devices.

[0038] Step 112: Filter out the path information and mount point information corresponding to non-vehicle system built-in devices from the mount record file as target identification information.

[0039] Step 113: Determine the external device corresponding to the target identification information as the target external device.

[0040] In this application, during operation, the vehicle-mounted system generates a dedicated mounting record file. This file is used to systematically store key information about all devices that have established connections with the vehicle-mounted system. Firstly, it stores path information, i.e., the storage path of the mounted devices within the vehicle-mounted system's file management architecture, which can be used to locate the data interaction position of the devices within the system. Secondly, it stores mounting point information, referring to the interface or node through which the device establishes a physical or logical connection with the vehicle-mounted system, which can be used to identify the connection port between the device and the system. By reading the mounting record file, a complete list and core identification data of all connected devices (including in-vehicle and external devices) in the vehicle-mounted system can be obtained, providing a basis for subsequent screening of external devices.

[0041] In this application, the built-in devices of the vehicle system refer to devices that are integrated with the vehicle system at the time of manufacture (such as built-in navigation modules, instrument panel control units, and storage modules integrated with the vehicle host). These devices do not need to be used as peripheral test objects. On the other hand, the external devices are devices that are connected to the system later through external interfaces (such as USB, Bluetooth, HDMI, etc.) (such as external dashcams, mobile phones, USB flash drives, external navigation devices, etc.). These devices are the target scope of stability testing.

[0042] In this application, the core of screening non-vehicle system built-in devices lies in distinguishing them by the characteristics of the device's path information or mount point information. For example, the path information of vehicle system built-in devices usually has a fixed prefix preset by the vehicle system (such as " / system / built-in / "), and the mount point information corresponds to a fixed node inside the system; while the path information of external devices is mostly a temporarily generated dynamic path, and the mount point information corresponds to an external physical interface. By identifying these characteristics, the information corresponding to the built-in devices is removed from the mount record file, and the remaining path information and mount point information of non-built-in devices are the target identification information.

[0043] In this application, because the path information and mount point information in the target identification information are unique, when each external device establishes a connection with the vehicle system, the system assigns it a unique storage path and a dedicated mount point. Therefore, each set of target identification information corresponds one-to-one with a specific external device. By matching the filtered target identification information with the currently mounted external devices, the target external devices that need to be tested for stability can be accurately located, ensuring the accuracy of subsequent test objects.

[0044] In this application, basic data is obtained by reading the path information and mount point information of the mounted devices in the mount record file, and information corresponding to non-vehicle system built-in devices is filtered from the mount record file. This can accurately exclude system native devices that do not need to be tested, avoid misjudging built-in devices as external devices to be tested, reduce invalid test processes caused by incorrect test objects, and significantly improve the accuracy and efficiency of target device positioning.

[0045] In step 120 above, the initiation of the automated cyclic test for the target external device can be specifically executed according to steps 121 to 122 as follows: Step 121: Obtain the loop parameters of the automated loop test, including the total number of tests and the duration of a single mount / unmount interval.

[0046] Step 122: Execute the device mounting operation and the device unmounting operation based on the loop parameters, wherein the device mounting operation is to mount the target external device to a preset mounting point, and the device unmounting operation is to unmount the target external device from the preset mounting point.

[0047] In this application, the total number of tests refers to the total number of executions of a single loop consisting of device mounting and unmounting operations. This can be used to define the overall scale of the test. The more tests, the more accurate the simulation results, but the longer the test will take. The interval between a single mounting and unmounting operation refers to the time interval between two adjacent mounting-unmounting loops. This can be used to simulate the time rhythm of users operating external devices in actual vehicle use scenarios, making the test more in line with real-world usage conditions and avoiding deviations from reality due to unreasonable intervals.

[0048] In this application, the preset mounting point is a fixed interface or logical node (e.g., a fixed USB interface number, a dedicated Bluetooth communication node) pre-designated in the vehicle system for connecting external devices, rather than a randomly selected mounting location.

[0049] In this application, the device mounting operation refers to connecting the target external device to a preset mounting point of the vehicle system to ensure that the connection path and interface resources between the device and the vehicle system are completely consistent each time it is mounted, avoiding differences in test conditions caused by different mounting points and eliminating interference from differences in the interface itself on the test results; the device unmounting operation refers to disconnecting the target external device from the preset mounting point, so that the vehicle system can release the recognition and resource occupation of the device.

[0050] This application clearly defines two types of loop parameters: the total number of tests and the duration of each load / unload interval. These parameters can be flexibly adjusted according to actual needs during testing, making the testing process adaptable to different testing objectives (such as factory quality inspection and long-term stability verification), thus improving the flexibility and applicability of the tests. The preset load point ensures that each load / unload operation is executed based on a fixed interface or node, eliminating test interference caused by random changes in load points (such as performance differences between different interfaces or different logical node resource allocations). Regardless of the number of loops, the connection path and resource usage between the device and the system remain consistent, ensuring that the basic conditions for each test are the same and improving the accuracy of the test results. Furthermore, test results from different devices can be compared under the same conditions, enhancing the comparability of the results.

[0051] In step 121 above, the loop parameter further includes a test mode identifier, which includes daily commuting mode, long-distance driving mode, or high-frequency plug-in / plug-out mode, wherein... When the test mode is identified as daily commuting mode, the total number of tests is set to the first test number, and the single mount / unmount interval is set to the first duration.

[0052] When the test mode is identified as long-distance driving mode, the total number of tests is set to the second number, the single loading and unloading interval is set to the second duration, the second number is less than the first number, and the second duration is greater than the first duration.

[0053] When the test mode is identified as high-frequency plug-in / plug-out mode, the total number of tests is set to the third number, the single load / unload interval is set to the third duration, the third number is greater than the first number, and the third duration is less than the first duration.

[0054] In this application, since the frequency of mounting or unmounting external devices varies with the usage scenario, different test scenarios can be simulated to avoid the test being out of touch with reality due to testing all scenarios with uniform parameters. Among them, the test mode identifier is the basis for distinguishing different usage scenarios of external devices, including daily commuting mode, long-distance driving mode or high-frequency plug-in / plug-out mode, and each type of identifier corresponds to a set of cyclic parameters.

[0055] In this application, the first number of times can specifically be 200 to 500 times, for example, 250 times, 300 times, or 400 times; the first duration can specifically be 0.5 hours to 2 hours, for example, 45 minutes, 1 hour, or 1.5 hours; the second number of times can specifically be 50 to 100 times, for example, 75 times, 80 times, or 60 times; the second duration can specifically be 6 hours to 10 hours, for example, 7 hours, 8.5 hours, or 9 hours; the third number of times can specifically be 3000 to 6000 times, for example, 4500 times, 5000 times, or 5500 times; the third duration can specifically be 10 seconds to 60 seconds, for example, 15 seconds, 45 seconds, or 30 seconds; this application does not make specific limitations in these respects.

[0056] In this application, the daily commuting mode can correspond to the scenario of users' daily short-distance travel (such as commuting to and from get off work). In this scenario, the frequency of mounting and unmounting external devices (such as connecting a mobile phone for screen mirroring or inserting a USB flash drive to play music) is at a moderate level. That is, users usually do not frequently plug and unplug devices, but they also do not continuously mount them as they would during long-distance driving. The total number of tests is set to the first test number, and the duration of a single mounting and unmounting interval is set to the first duration, in order to simulate the device usage rhythm of occasional and moderately spaced plugging and unplugging during daily commuting.

[0057] In this application, the long-distance driving mode can correspond to the scenario of users traveling long distances. In such scenarios, once an external device is attached, it is usually used continuously until the end of the trip, and the attachment and unloading frequency is low. Therefore, the total number of tests is set to the second number, and it is clear that the second number is less than the first number; the single attachment and unloading interval is set to the second duration, and it is clear that the second duration is longer than the first duration, in order to simulate the device usage rhythm of less plugging and unplugging and long intervals in long-distance driving.

[0058] In this application, the high-frequency plugging and unplugging mode corresponds to scenarios where users frequently change external devices, such as taxi drivers frequently plugging in USB drives to update music, or repair personnel repeatedly connecting diagnostic equipment. In such scenarios, the frequency of external device loading and unloading is high. Therefore, the total number of tests is set to the third count, and it is clearly stated that the third count is greater than the first count; the interval between a single loading and unloading is set to the "third duration," and it is clearly stated that the third duration is less than the first duration, in order to simulate the device usage rhythm of frequent plugging and unplugging and short intervals in high-frequency scenarios.

[0059] In this application, by classifying the test modes into daily commuting mode, long-distance driving mode, and high-frequency plug-in / plug-out mode, and configuring corresponding total number of tests and single loading / unloading intervals with clear size relationships for each of the three modes, the test can accurately match the real usage rhythm of external devices in different vehicle scenarios, simulate the stability issues that users may encounter in actual use, and improve the practical value of the test. Furthermore, by configuring differentiated parameters, the resource waste caused by uniform parameter testing can be avoided. Test time, computing power, and other resources can be reasonably allocated according to scenario requirements, optimizing resource consumption and improving the efficiency of peripheral stability testing. In step 130 above, the real-time monitoring of the operating status of the target external device and the resource status of the vehicle system can be specifically performed according to steps 131 to 133 as follows: Step 131: Monitor the mounting validity of the target external device after the device mounting operation. The mounting validity includes whether the target file exists at the preset mount point and whether file reading and writing are normal.

[0060] Step 132: Monitor the uninstallation validity of the target external device after the device uninstallation operation. The uninstallation validity includes whether the preset mount point is empty and whether the device occupancy status is released.

[0061] Step 133: Monitor the resource status of the vehicle system, including the number of file descriptors, the status of the storage management service process, and the CPU and memory usage.

[0062] In this application, the mounting validity monitoring is to verify whether successful mounting is equivalent to functional availability, avoiding invalid mountings that only identify the device but cannot be used normally. Specifically, this can be determined by judging whether the target file exists at the preset mounting point and whether file read and write are normal. The preset mounting point is a fixed connection node assigned by the vehicle system to the target external device, such as the system logical path corresponding to a dedicated USB interface or the dedicated identification path of an external storage device. The target file is an identifier file that should be generated or included with the device after normal mounting, such as the system identification configuration file of an external USB flash drive or the driver identification file of an external navigation module. If the target file exists at the preset mounting point, it means that the vehicle system has successfully identified the device and established a basic connection, which is a prerequisite for valid mounting; if it does not exist, the mounting is directly judged as failed.

[0063] In this application, after confirming the existence of the target file, the device function is further verified by simulating actual user operations, such as reading the contents of the target file and writing to a temporary test file. If the read and write operations can be completed normally, it indicates that the device is not only recognized by the system, but also has normal data interaction capabilities. If read errors or write failures occur, it is determined that although the mounting is successful on the surface, the function is invalid, and it is necessary to locate the device or system adaptation problem.

[0064] In this application, the uninstallation validity monitoring is to verify whether the completion of uninstallation is equivalent to the complete release of resources, and to avoid the residual problem of the device being physically disconnected but system resources still being occupied. Specifically, this can be determined by judging whether the preset mount point is empty and whether the device's occupied state has been released. After the uninstallation operation is completed, it can be checked whether all files related to the target external device under the preset mount point have been completely cleared. If the mount point is empty, it means that the device has been completely disconnected at the system file level; if there are still residual files, it may cause path conflicts when other devices are mounted in the future, or occupy system storage resources.

[0065] In this application, in addition to the document level, it is also possible to further monitor whether the hardware and system process resources corresponding to the device are released. For example, whether the USB port occupied by the target external device is restored to an idle state, whether the Bluetooth communication channel is unbound, and whether the driver process associated with the device exits normally. If the device occupancy state is not released, the resource will be unable to be used by other devices (such as the inability to connect a new USB flash drive after the USB port is occupied). Long-term accumulation may also lead to the problem of system resource exhaustion.

[0066] In this application, system resource status monitoring is used to determine whether the operation of the target external device affects the overall stability of the vehicle system. Specifically, this can be determined through the number of file descriptors, the status of the storage management service process, and CPU / memory usage. Each external device connection and file read / write operation consumes a file descriptor, which can be used to identify the interaction channel between the system and the device or file. The number of file descriptors has a system limit; by monitoring the number of file descriptors, leaks of unreleased file descriptors after mounting and unmounting can be detected in a timely manner, preventing the system from failing to recognize new devices or file operations due to descriptor exhaustion. The storage management service process is the core of the vehicle system's function of managing the storage of external devices. The process can be used for mounting and allocation, data read / write scheduling, and storage resource reclamation. By monitoring whether it is running normally, whether it crashes, or whether it freezes, we can ensure that the system's ability to manage devices is not impaired. If the storage management service process is abnormal, even if the device itself is normal, it will lead to mounting and unmounting failures or data loss. By monitoring the CPU usage and memory usage of the vehicle system during device mounting, unmounting, and operation, we can determine whether the device operation has caused system resource overload. For example, frequent mounting may cause a sudden increase in CPU usage, and device abnormalities may cause memory leaks. If resource usage exceeds the normal range, it will cause the vehicle system to freeze and even affect the normal operation of core functions such as navigation and dashboard display.

[0067] In this application, the monitoring of mounting effectiveness not only verifies whether the device is mounted, but also verifies the availability of the function through file read and write. The monitoring of unmounting effectiveness not only verifies whether the device is disconnected, but also verifies whether the resource release is thorough. This can avoid the disconnect between the test and the actual user experience, and ensure that the stability test results directly correspond to real usage scenarios. Monitoring core resource dimensions such as the number of file descriptors in the vehicle system, the process status of the storage management service, and the CPU and memory usage can reveal the impact of external devices on the system from the perspectives of device interaction channels, system management capabilities, and overall operating load. Moreover, all monitoring indicators are quantifiable and traceable. If an anomaly occurs, the problem link can be quickly located, improving the efficiency of external device stability testing.

[0068] In step 140 above, generating test logs based on the running status and the resource status can be specifically performed according to steps 141 to 143 as follows: Step 141: Record the timestamp, operation type, and operation result of each device mounting and unmounting operation in the test log.

[0069] Step 142: Record the occurrence time, anomaly type, and corresponding system resource snapshot of the abnormal running status in the test log.

[0070] Step 143: Send the test log to the preset path of the vehicle system according to the naming format of "test date_device type_test mode.log".

[0071] In this application, for each device mounting and unmounting operation, three types of key information are recorded in the test log: timestamp, operation type, and operation result. The timestamp indicates the specific time the operation was executed, allowing for precise location of each mounting or unmounting event. When anomalies are subsequently detected, the timestamp can be used to link to the corresponding operation, avoiding ambiguity in the time dimension. The operation type clearly indicates whether the operation was a device mounting or unmounting, directly distinguishing the nature of the operation and enabling log readers to quickly determine the test action corresponding to a particular record. The operation result, based on the mounting and unmounting validity determination results mentioned above, records whether the operation was successful or failed, directly reflecting the execution effect of a single operation.

[0072] In this application, when an abnormal operating status of the target external device is detected, the test log records the occurrence time, type of abnormality, and corresponding system resource snapshot. The occurrence time is recorded as a timestamp, ensuring a precise correlation between the abnormality and the corresponding test step (e.g., 10 seconds after a certain mounting), providing a temporal basis for tracing the triggering conditions of the abnormality. The abnormality type is clearly categorized and labeled according to its manifestation, such as mounting validity abnormality and unmounting validity abnormality, making the nature of the abnormality immediately clear and facilitating subsequent analysis. The corresponding system resource snapshot refers to the real-time data record of the core resource status of the vehicle system at the moment the abnormality occurs, including the number of file descriptors, the status of the storage management service process, and CPU / memory usage. This is equivalent to a frozen record of the abnormal situation, intuitively presenting the system's resource background at the time of the abnormality, providing direct data support for analyzing whether the abnormality was caused by system resource issues.

[0073] In this application, log files are named "Test Date_Device Type_Test Mode.log", where "Test Date" is the date the test was executed (e.g., "20241030"), "Device Type" is the specific category of the external device to be tested (e.g., "USB flash drive", "dashcam", "phone projection module"), and "Test Mode" is the mode corresponding to this test (e.g., "daily commuting mode" or "high-frequency plug-and-play mode"). This naming convention ensures that the core information of the log file (time, object, scenario) is directly reflected in the filename, allowing for quick identification of the test scenario corresponding to the log without opening the file.

[0074] In this application, by recording the timestamps, operation types, and operation results of each device mounting and unmounting operation in the test log, the entire testing process can be completely reconstructed. If anomalies are subsequently discovered, the fundamental problems in the specific operational steps can be quickly traced back, thereby improving the efficiency of external device stability testing. By recording the occurrence time, anomaly type, and corresponding system resource snapshots of abnormal operating states, the system resource background at the time of the anomaly can be captured, intuitively presenting the correlation between the anomaly and system resources, significantly reducing the complexity of troubleshooting the cause of the anomaly. By storing the test logs in the preset path of the vehicle system according to the naming format of "test date_device type_test mode.log", the core information of the logs (time, device, mode) can be directly identified by the file name, and centralized management of the logs can be achieved, avoiding the difficulty of finding logs caused by scattered storage, and significantly improving the efficiency of subsequent review of test results, tracing historical data, or sharing logs.

[0075] Furthermore, in step 140 above, determining the stability assessment result of the target external device based on the test log can be specifically performed according to steps 144 to 146 as follows: Step 144: Extract the total number of executions, the number of exceptions, and the distribution of exception types of the automated loop test from the test log.

[0076] Step 145: Calculate the stability pass rate based on the total number of executions and the number of exceptions, whereby the stability pass rate = (total number of executions - number of exceptions) / total number of executions × 100%.

[0077] Step 146: Generate a stability assessment report based on the stability pass rate and anomaly type distribution. The stability assessment report includes assessment conclusions of low risk, medium risk, or high risk.

[0078] In this application, the total number of executions of the automated loop test refers to the total number of complete loops consisting of device mounting and device unmounting operations recorded in the log, which can directly reflect the coverage of the test; the number of anomalies is the total number of times marked as operation failure or abnormal running status in the log, which is the core basis for judging stability defects; the anomaly type distribution is the statistical classification of all anomaly counts according to the nature of the anomalies, used to judge which type of stability problem is more prominent, and to provide a basis for subsequent risk classification.

[0079] In this application, a stability assessment report is generated based on the stability pass rate and anomaly type distribution, including assessment conclusions of low risk, medium risk, or high risk. A low-risk assessment conclusion corresponds to a high stability pass rate, such as a pass rate greater than or equal to 99%, and anomalies that are mostly minor (e.g., occasional mount response delays, but file read / write eventually return to normal, with no system resource anomalies), indicating excellent device stability in the test scenario, with a low probability of problems and minimal impact. A medium-risk assessment conclusion typically corresponds to a moderate stability pass rate, such as a pass rate greater than or equal to 90% but less than 99%, and anomalies that have some impact (e.g., a small amount of uninstallation residue, but manual operation can recover it, with no risk of system crash), indicating overall device stability, but with localized issues requiring optimization that do not affect core usage but need attention. A high-risk assessment conclusion typically corresponds to a low stability pass rate, such as less than 90%, and anomalies that have a serious impact (e.g., frequent mount failures, device crashes, or continuous CPU and memory overruns), indicating significant device stability defects that may affect normal user operation or even vehicle system safety, requiring priority rectification.

[0080] In this application, by extracting the total number of executions, the number of anomalies, and the distribution of anomaly types from the test logs, the stability pass rate is calculated based on quantitative data. This avoids the bias caused by relying on subjective descriptions to judge stability, and ensures the consistency and credibility of the evaluation results under different scenarios. The stability pass rate is presented as a percentage and is assigned a graded evaluation conclusion of low, medium, and high risk. Combined with the distribution of anomaly types, the severity of anomalies is distinguished, so that subsequent optimization work can accurately focus on high-priority issues and improve the efficiency of external device stability testing.

[0081] Based on the technical solution proposed in this application, the method may further perform the following steps 134 to 135: Step 134: During the automated loop test, the cumulative number of abnormal operating states is counted. The abnormal operating states include invalid mounting or invalid unmounting.

[0082] Step 135: When the cumulative number of tests reaches a preset error threshold, terminate the automated loop test and record the reason for termination in the test log.

[0083] In this application, "invalid mounting" specifically refers to situations where, after a device mounting operation, the preset mount point does not have a target file, or there are abnormal file read / write operations, preventing the device from functioning normally; "invalid unmounting" specifically refers to situations where, after a device unmounting operation, the preset mount point still has residual files, or the hardware or process resources occupied by the device have not been released, indicating that the connection has not been completely disconnected.

[0084] In this application, the preset error threshold is the maximum tolerable number of exceptions set in advance according to the test objective. It is the core criterion for determining whether the test needs to be terminated, so as to avoid the test from continuing indefinitely due to unlimited allowance of exceptions. After the test is terminated, the key information of the termination must be clearly recorded in the test log, including: the test cycle progress at the time of termination, the cumulative number of exceptions, and the preset error threshold, so as to ensure that when reviewing the log later, the reason for the test not being completed can be directly known without having to backtrack all test records.

[0085] In this application, the preset error thresholds include a reminder threshold, a warning threshold, and an emergency threshold. When the cumulative number of errors reaches the reminder threshold (e.g., 1% of the total number of loops), a visual cue is generated to remind the test engineer. When the cumulative number of errors reaches the warning threshold (e.g., 5% of the total number of loops), an email notification is generated. When the cumulative number of errors reaches the emergency threshold (e.g., 10% of the total number of loops), the automated loop test is terminated to prevent the test engineer from missing early risk signals.

[0086] In this application, two types of anomalies strongly related to the core interactive functions of the device are counted: invalid mounting and invalid unmounting. This can eliminate non-critical interference items and make the cumulative number of anomalies truly reflect the stability defects of the device. When the cumulative number of anomalies reaches a preset threshold, it indicates that the device has exceeded the range of tolerable stability defects. At this time, the test is terminated, which can avoid continuing to test and consuming time, computing power and other resources, thus improving test efficiency.

[0087] Based on the technical solution proposed in this application, the method may further perform the following steps 210 to 230: Step 210: Obtain the environmental simulation parameters of the vehicle system, including vibration frequency, temperature range and electromagnetic interference intensity.

[0088] Step 220: Based on the environmental simulation parameters, control the environmental simulation device to apply corresponding environmental influences to the target external device.

[0089] Step 230: During the duration of the environmental impact, perform the automated cyclic test.

[0090] In this application, by incorporating environmental factors into an automated cyclic testing system, the test scenarios are ensured to closely resemble real-world vehicle environments. The environmental simulation parameters include vibration frequency, temperature range, and electromagnetic interference intensity. The vibration frequency corresponds to the differences in road conditions during vehicle operation, such as low-frequency slight vibrations on flat urban roads and medium-to-high-frequency vibrations on bumpy rural roads. The parameters need to specify the simulated vibration frequency range or fixed value to reproduce the impact of different road conditions on the stability of the device connection (e.g., poor contact at the interface due to vibration). The temperature range corresponds to the extreme temperature environment of the vehicle, such as the high temperature inside the car after being exposed to the sun in summer. The parameters need to specify the upper and lower limits of the temperature and the duration of maintenance to verify whether the device's mounting or unmounting function is normal under high and low temperatures (e.g., decreased conductivity of the device interface metal contacts at low temperatures leading to mounting failure). The electromagnetic interference intensity corresponds to the complex electromagnetic environment inside the vehicle, such as electromagnetic signal interference generated when electronic devices such as car navigation, audio, and radar are working. The parameters need to specify the frequency range (e.g., 100MHz-2GHz) and intensity level (e.g., 30-50dBμV / m) of the interference signal to verify the stability of data interaction of the device under electromagnetic interference (e.g., interference causing interruption of file reading and writing).

[0091] In this application, environmental simulation parameters such as vibration frequency, temperature range, and electromagnetic interference intensity correspond to common environmental challenges encountered in the actual use of vehicle-mounted external devices, making the test scenario closely resemble the real-world vehicle environment and enhancing the practical value of the test results. By using professional environmental simulation equipment to precisely apply environmental influences according to the set parameters, it is ensured that the intensity, duration, and range of environmental factors are stable and meet the parameter requirements. This not only guarantees the reproducibility of test conditions and avoids test deviations caused by environmental fluctuations, but also makes the test results of different external devices comparable under the same environment, facilitating the selection of better devices. It ensures stable operation even in complex environments such as high and low temperatures, vibration, and electromagnetic interference, thereby mitigating the risk of equipment failure in actual vehicle use from the source and effectively improving the user experience and the overall reliability of the vehicle system.

[0092] Based on the technical solution proposed in this application, the method may further include the following steps 240 to 250: Step 240: When the vehicle system is connected to multiple external devices, an independent test process is assigned to each external device.

[0093] Step 250: Control each test process to execute the automated loop test in parallel, and record the test data of each external device in the test log.

[0094] In this application, by creating a dedicated test task process for each external device, multiple devices can be tested simultaneously without interference, thereby effectively improving testing efficiency. Furthermore, by distinguishing and recording the test data of each external device in the test log, it is ensured that the test data of each device can be extracted and analyzed independently. Specifically, the distinguishing and recording can be achieved by adding a unique identifier to the test data of each device in the test log. This identifier is bound to the unique information of the device, and all test data related to the device is associated with this unique identifier.

[0095] In this application, by assigning an independent test process to each external device and controlling each process to execute automated cyclical tests in parallel, the testing tasks of all external devices can be advanced synchronously. The overall test time depends only on the single device with the longest test time, rather than the sum of the test times of all devices, which significantly shortens the overall test cycle in multi-device scenarios and significantly improves test efficiency. At the same time, the independent test process has its own dedicated system resources and the processes are isolated from each other, which can prevent the test of one device from occupying resources or causing anomalies to interfere with the test of other devices, ensuring that the test results of each device only reflect its own stability and improving the accuracy of the test results.

[0096] To enable those skilled in the art to better understand this application, the following is combined with Figure 2 The present application will use a specific application scenario to illustrate the test method for the stability of vehicle peripherals proposed in this application.

[0097] See Figure 2 This document illustrates a detailed flowchart of a method for testing the stability of vehicle peripherals in one embodiment of this application, as shown below. Figure 2 As shown, the method may specifically include steps 201 to 216: Step 201, Start the test.

[0098] Step 202: Identify the target external device to be tested.

[0099] Step 203: Determine whether the target external device has been successfully identified. If yes, proceed to step 204; otherwise, proceed to step 205.

[0100] Step 204: Initialize the test environment.

[0101] Step 205: Record the error and terminate the test.

[0102] Step 206: Perform the device unloading operation.

[0103] Step 207: Perform the device mounting operation.

[0104] Step 208: Verify the validity of the mounted status or the unmounted status.

[0105] Step 209: Monitor the resource status of the vehicle system.

[0106] Step 210: Count the cumulative number of abnormal operating states.

[0107] Step 211: Determine whether the cumulative number of errors has reached the preset error threshold. If yes, proceed to step 212; otherwise, proceed to step 213.

[0108] Step 212, terminate the test.

[0109] Step 213, increment the cumulative count by 1.

[0110] Step 214: Determine whether the cumulative number of tests has reached the total number of tests. If yes, proceed to step 215; otherwise, proceed to step 206.

[0111] Step 215, the test ends normally.

[0112] Step 216: Generate a test report.

[0113] Based on the technical solution proposed in this application, the target external device to be tested can be accurately identified by acquiring target recognition information from the vehicle system, avoiding confusion between peripherals and vehicle internals, and improving the targeting and efficiency of testing. By automatically and alternately executing device loading and unloading operations, high-frequency and long-term testing can be achieved without manual intervention. This can simulate the real working conditions of users frequently plugging and unplugging peripherals, efficiently capture occasional anomalies, and promptly locate potential stability hazards in the dynamic connection process of the device. By synchronously monitoring the operating status of the target external device and the resource status of the vehicle system in real time, both the stability of the device itself and its impact on the system can be taken into account, ensuring the comprehensiveness of the stability assessment. The test log generated based on the monitoring data and the evaluation results determined accordingly can avoid subjective judgment bias. At the same time, the log can trace the specific working conditions under which the anomaly occurred, providing clear data basis for subsequent device defect investigation and vehicle system compatibility optimization, thereby improving the accuracy and efficiency of vehicle peripheral testing.

[0114] The following describes an embodiment of the apparatus described in this application, which can be used to perform the vehicle peripheral stability testing method described in the above embodiments of this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the vehicle peripheral stability testing method described above in this application.

[0115] Figure 3 A block diagram of a testing apparatus for the stability of vehicle peripherals according to one embodiment of this application is shown.

[0116] Reference Figure 3 According to one embodiment of the present application, a test device 300 for the stability of vehicle peripherals includes: an acquisition unit 301, a test unit 302, a monitoring unit 303, and an evaluation unit 304.

[0117] The system includes: an acquisition unit 301 for acquiring target identification information from the vehicle system and locating the target external device to be tested based on the target identification information; a testing unit 302 for initiating an automated cyclic test for the target external device, the automated cyclic test including alternating execution of device mounting and unmounting operations; a monitoring unit 303 for monitoring the operating status of the target external device and the resource status of the vehicle system in real time during the automated cyclic test; and an evaluation unit 304 for generating a test log based on the operating status and the resource status, and determining the stability evaluation result of the target external device based on the test log.

[0118] In some embodiments of this application, based on the foregoing scheme, the acquisition unit 301 is configured to: read the mounting record file of the vehicle system, the mounting record file containing path information and mounting point information of all mounted devices; filter out the path information and mounting point information corresponding to non-vehicle system built-in devices from the mounting record file as target identification information; and determine the external device corresponding to the target identification information as the target external device.

[0119] In some embodiments of this application, based on the previous scheme, the test unit 302 is configured to: obtain the loop parameters of the automated loop test, the loop parameters including the total number of tests and the duration of a single mount / unmount interval; and execute the device mount operation and the device unmount operation based on the loop parameters, wherein the device mount operation is to mount the target external device to a preset mount point, and the device unmount operation is to unmount the target external device from the preset mount point.

[0120] In some embodiments of this application, the loop parameter further includes a test mode identifier, which includes a daily commuting mode, a long-distance driving mode, or a high-frequency plug-in / unplug mode. When the test mode identifier is a daily commuting mode, the total number of tests is set to the first number, and the single loading / unloading interval is set to the first duration. When the test mode identifier is a long-distance driving mode, the total number of tests is set to the second number, and the single loading / unloading interval is set to the second duration, wherein the second number is less than the first number, and the second duration is greater than the first duration. When the test mode identifier is a high-frequency plug-in / unplug mode, the total number of tests is set to the third number, and the single loading / unloading interval is set to the third duration, wherein the third number is greater than the first number, and the third duration is less than the first duration.

[0121] In some embodiments of this application, based on the foregoing scheme, the monitoring unit 303 is configured to: monitor the mounting validity of the target external device after the device mounting operation, the mounting validity including whether the target file exists at the preset mounting point and whether file reading and writing are normal; monitor the unloading validity of the target external device after the device unloading operation, the unloading validity including whether the preset mounting point is empty and whether the device occupancy status is released; and monitor the resource status of the vehicle system, the resource status including the number of file descriptors, the storage management service process status, and the CPU memory usage rate.

[0122] In some embodiments of this application, based on the foregoing scheme, the device further includes a statistics unit, which is configured to: count the cumulative number of abnormal operating states during the automated cyclic test, wherein the abnormal operating states include invalid mounting or invalid unmounting; when the cumulative number reaches a preset error threshold, terminate the automated cyclic test and record the termination reason in the test log.

[0123] In some embodiments of this application, based on the foregoing scheme, the device further includes an environmental simulation unit, which is configured to: acquire environmental simulation parameters of the vehicle system, the environmental simulation parameters including vibration frequency, temperature range and electromagnetic interference intensity; control the environmental simulation device to apply corresponding environmental influences to the target external device based on the environmental simulation parameters; and execute the automated cyclic test steps during the continuous process of the environmental influences.

[0124] In some embodiments of this application, based on the foregoing scheme, the device further includes a parallel unit, which is configured to: when the vehicle system is connected to multiple external devices, allocate an independent test process to each external device; control each test process to execute the automated cyclic test in parallel, and distinguish and record the test data of each external device in the test log.

[0125] As another embodiment of this application, a computer program product or computer program is also provided, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods described in the above embodiments.

[0126] As another embodiment of this application, a computer-readable storage medium is also provided. This computer-readable storage medium may be included in the vehicle described in the above embodiments, or it may exist independently and not installed in the vehicle. The computer-readable storage medium carries one or more programs that, when executed by the vehicle, cause the vehicle to perform the methods described in the above embodiments.

[0127] Based on the same inventive concept, this application also provides a vehicle. (Reference) Figure 4 The diagram illustrates a structural schematic of a vehicle according to one embodiment of this application. The vehicle includes one or more memories 404, one or more processors 402, and at least one computer program (program code) stored in the memories 404 and executable on the processors 402. When the processors 402 execute the computer program, they implement the method described above.

[0128] Among them, Figure 4 In this document, a bus architecture (represented by bus 400) is used. Bus 400 may include any number of interconnected buses and bridges, linking various circuits including one or more processors represented by processor 402 and memory represented by memory 404. Bus 400 may also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. Bus interface 405 provides an interface between bus 400 and receiver 401 and transmitter 403. Receiver 401 and transmitter 403 may be the same element, i.e., a transceiver, providing a unit for communicating with various other devices over a transmission medium. Processor 402 is responsible for managing bus 400 and general processing, while memory 404 can be used to store data used by processor 402 during operation.

[0129] The functions described herein may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions may be stored as one or more instructions or codes on or transmitted via a computer-readable medium. Other examples and embodiments are within the scope and spirit of this application and the appended claims. For example, due to the nature of software, the functions described above may be implemented using software executed by a processor, hardware, firmware, hardwired, or any combination thereof. Furthermore, the functional units may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit.

[0130] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0131] The units described as separate components may or may not be physically separate. Similarly, the components of the control device may or may not be physical units; they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0132] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium, including instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0133] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for testing the stability of vehicle-mounted peripherals, characterized in that, The method includes: Acquire target recognition information from the vehicle system, and locate the target external device to be tested based on the target recognition information; Initiate an automated loop test for the target external device, the automated loop test including alternating execution of device mounting and device unmounting operations; During the automated cyclic testing process, the operating status of the target external device and the resource status of the vehicle system are monitored in real time. Test logs are generated based on the operating status and resource status, and the stability assessment result of the target external device is determined based on the test logs.

2. The method according to claim 1, characterized in that, The step of acquiring target recognition information from the vehicle system and locating the target external device to be tested based on the target recognition information includes: Read the mounting record file of the vehicle system, which contains path information and mounting point information of all mounted devices; The path information and mount point information corresponding to non-vehicle system built-in devices are filtered from the mount record file and used as target identification information. The external device corresponding to the target identification information is identified as the target external device.

3. The method according to claim 1, characterized in that, The initiation of the automated cyclic test for the target external device includes: Obtain the loop parameters of the automated loop test, including the total number of tests and the duration of a single mount / unmount interval; The device mounting operation and the device unmounting operation are performed based on the loop parameters, wherein the device mounting operation is to mount the target external device to a preset mounting point, and the device unmounting operation is to unmount the target external device from the preset mounting point.

4. The method according to claim 3, characterized in that, The cycle parameters also include a test mode identifier, which includes daily commuting mode, long-distance driving mode, or high-frequency plugging and unplugging mode. When the test mode is identified as daily commuting mode, the total number of tests is set to the first test number, and the single mount / unmount interval is set to the first duration. When the test mode is identified as long-distance driving mode, the total number of tests is set to the second number, the single loading and unloading interval is set to the second duration, the second number is less than the first number, and the second duration is greater than the first duration; When the test mode is identified as high-frequency plug-in / plug-out mode, the total number of tests is set to the third number, the single load / unload interval is set to the third duration, the third number is greater than the first number, and the third duration is less than the first duration.

5. The method according to claim 1, characterized in that, The real-time monitoring of the operating status of the target external device and the resource status of the vehicle system includes: Monitor the mounting validity of the target external device after the device mounting operation. The mounting validity includes whether the target file exists at the preset mount point and whether file reading and writing are normal. Monitor the uninstallation validity of the target external device after the device uninstallation operation. The uninstallation validity includes whether the preset mount point is empty and whether the device occupancy status is released. Monitor the resource status of the vehicle system, including the number of file descriptors, the status of the storage management service process, and the CPU and memory usage.

6. The method according to claim 5, characterized in that, The method further includes: During the automated cyclic testing process, the cumulative number of abnormal operating states is counted, including invalid mounting or invalid unmounting. When the cumulative number of tests reaches a preset error threshold, the automated loop test is terminated, and the reason for termination is recorded in the test log.

7. The method according to claim 1, characterized in that, The method further includes: The environmental simulation parameters of the vehicle system are obtained, including vibration frequency, temperature range and electromagnetic interference intensity. Based on the environmental simulation parameters, the environmental simulation device is controlled to apply corresponding environmental influences to the target external device; During the duration of the environmental impact, the automated cyclical test steps are performed.

8. The method according to claim 1, characterized in that, The method further includes: When the vehicle system is connected to multiple external devices, an independent test process is assigned to each external device; The automated cyclic test is executed in parallel by controlling each test process, and the test data of each external device is recorded separately in the test log.

9. A computer-readable storage medium storing at least one computer program instruction, the at least one computer program instruction being loaded and executed by a processor to implement the method as claimed in any one of claims 1 to 8.

10. A vehicle, characterized in that, The vehicle includes one or more processors and one or more memories, wherein at least one piece of program code is stored in the one or more memories, and the at least one piece of program code is loaded and executed by the one or more processors to implement the method as claimed in any one of claims 1 to 8.

Images