Multi-device test control management method, system, device and storage medium

Abstract

The application provides a multi-device test control management method, system, device and storage medium, the method comprising: monitoring the running state of a terminal through a terminal control module, and reporting state data to a management control module through a multi-channel control protocol; monitoring the network state of a routing device through a network control module, and reporting state data to the management control module through the multi-channel control protocol; monitoring the state of a SIM card through a SIM card control module, and reporting state data to the management control module through the multi-channel control protocol; the management control module judging whether the monitored device is abnormal according to the received state data; if it is judged that an abnormality occurs, the management control module sends a control instruction to the function control module reporting the state data through the multi-channel control protocol. The efficiency and reliability of multi-device test management are significantly improved.

Description

Technical Field

[0001] This application relates to the field of equipment control and management technology, and in particular to a multi-device test control and management method, system, device and storage medium. Background Technology

[0002] Currently, in the field of multi-device test control and management, with the rapid development of communication technology, the demand for automated testing of devices such as mobile terminals, routing devices, and Subscriber Identity Module (SIM) cards is increasing. Existing technologies typically employ decentralized control schemes: mobile phone control relies on the Android Debug Bridge (ADB) tool for single-device management; network control is performed through the router's built-in management interface or dedicated tools; and SIM card control relies on the mobile phone's built-in functions.

[0003] Existing decentralized control methods are cumbersome to operate, resulting in low management efficiency. Summary of the Invention

[0004] This application provides a multi-device test control and management method, system, device, and storage medium to solve the defects of the existing decentralized control methods, which are cumbersome to operate and result in low management efficiency.

[0005] This application provides a multi-device test control and management method, including the following steps: The terminal control module monitors the terminal's operating status and reports the status data to the management control module via a multi-channel control protocol. The network control module monitors the network status of the routing device and reports the status data to the management control module through the multi-channel control protocol. The SIM card status is monitored by the user identification module and the SIM card control module, and the status data is reported to the management control module through the multi-channel control protocol. The management and control module determines whether the monitored device is malfunctioning based on the received status data. If an anomaly is detected, the management control module sends a control command to the function control module that reports the status data via the multi-channel control protocol. The multi-channel control protocol is used for data interaction between the management control module and the terminal control module, the network control module, and the SIM card control module.

[0006] In some embodiments, the data packets of the multichannel control protocol include: The module type field is used to identify the terminal control module, network control module, or SIM card control module; The device serial number field, combined with the module type field, is used to uniquely identify each monitored physical device in the multi-device test control and management system.

[0007] In some embodiments, the data packets of the multichannel control protocol further include at least one of the following fields: The packet type field is used to distinguish between request packets and response packets; The protocol type field is used to distinguish between status detection functions and power control functions; The data length field indicates the length in bytes of the data content field; The data content field is used to carry status information or control commands; The verification field is used to perform integrity checks on data packets. The end identifier field is used to indicate the end of the data packet.

[0008] In some embodiments, it also includes: The function control module feeds back the execution result of the control command to the management control module through the multi-channel control protocol.

[0009] In some embodiments, monitoring the terminal's operating status via the terminal control module includes: The connection status of the terminal is monitored through the Android Debug Bridge (ADB) service, and the connection status includes at least one of online, offline, and unauthenticated. The terminal's operating status is monitored by the ATX service, which includes at least one of the following: normal, frozen, insufficient storage space, low battery, high temperature, and ATX service abnormality.

[0010] In some embodiments, monitoring the network status of the routing device via the network control module includes: Match the terminal associated with the network control module based on the device serial number; The operating status of the routing device is determined by querying the network connection status of the terminal and by performing a network PING test on the terminal side. The operating status of the routing device includes at least one of the following: normal, terminal connection to the route failed, and terminal connected to the route but had no network access.

[0011] In some embodiments, monitoring the status of the SIM card via the SIM card control module includes: By interacting with the microcontroller service of the SIM card slot, the physical state of the card slot is obtained, including at least one of idle, in use, and no card; The logical registration status of the SIM card is queried through the terminal's ATX service. The registration status includes at least one of normal, no card, and locked.

[0012] In some embodiments, the multi-device test control and management system further includes a power controller; the method further includes: The power controller provides controllable power output to the terminal, routing device, or SIM card slot. The control commands include power control commands; The function control module performs a power-off and restart operation on the abnormal physical device through the power controller according to the power control command.

[0013] In some embodiments, it also includes: When a new type of device is connected, the management and control module assigns a new module type field value to the new type of device and assigns a new device serial number to the specific physical device under that type; The management control module and each functional control module identify and manage the new type of device based on the module type field and the new device serial number.

[0014] This application also provides a multi-device test control and management system, including: Management and control module; and Multiple functional control modules are communicatively connected to the management and control module; the multiple functional control modules include at least a terminal control module, a network control module, and a SIM card control module. The management control module and each functional control module interact with each other via a multi-channel control protocol. The terminal control module is used to monitor the operating status of the terminal and report the status data to the management control module through the multi-channel control protocol; The network control module is used to monitor the network status of the routing device and report the status data to the management control module through the multi-channel control protocol. The SIM card control module is used to monitor the status of the SIM card and report the status data to the management control module through the multi-channel control protocol. The management and control module is used to determine whether the monitored device has malfunctioned based on the received status data. If an malfunction is determined, a control command is sent to the function control module that reports the status data through the multi-channel control protocol.

[0015] This application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the multi-device test control and management method described above.

[0016] This application also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the multi-device test control and management method as described above.

[0017] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the multi-device test control and management method described above.

[0018] The multi-device test control and management method, system, equipment, and storage medium provided in this application achieve unified status monitoring and collaborative control of three types of devices—terminals, routers, and SIM cards—through a multi-channel control protocol, significantly improving the efficiency and reliability of multi-device test management. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating the multi-device test control and management method provided in this application.

[0021] Figure 2 This is an architecture diagram of the multi-device test control and management method provided in the embodiments of this application.

[0022] Figure 3 This is a schematic diagram of the multi-channel control protocol format definition provided in the embodiments of this application.

[0023] Figure 4 This is a flowchart of the terminal control module provided in the embodiments of this application.

[0024] Figure 5 This is a flowchart illustrating the network control module provided in an embodiment of this application.

[0025] Figure 6 This is a flowchart illustrating the SIM card control module provided in an embodiment of this application.

[0026] Figure 7 This is a schematic diagram of the structure of the multi-device test control and management system provided in the embodiments of this application.

[0027] Figure 8 This is a schematic diagram of the hardware structure of the multi-device test control and management system provided in the embodiments of this application.

[0028] Figure 9 This is a module architecture diagram of the multi-device test control and management system provided in this application embodiment.

[0029] Figure 10 This is a schematic diagram of the physical structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions 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, 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.

[0031] Currently, in the field of multi-device test control and management, with the rapid development of communication technology, the demand for automated testing of devices such as mobile terminals, routing devices, and Subscriber Identity Module (SIM) cards is increasing. Existing technologies typically employ decentralized control schemes: mobile phone control relies on the Android Debug Bridge (ADB) tool for single-device management; network control is performed through the router's built-in management interface or dedicated tools; and SIM card control relies on the mobile phone's built-in functions.

[0032] Existing decentralized control methods are cumbersome to operate, resulting in low management efficiency.

[0033] In view of this, this application provides a multi-device test control and management method, which adopts a multi-channel control protocol to achieve unified and efficient control and management of terminals, networks, and SIM cards, improving the coordination and reliability of device control and reducing maintenance costs. It provides a stable, reliable, and 24 / 7 testing capability for application (APP) visualization testing and quality management.

[0034] Figure 1 This is a flowchart illustrating the multi-device test control and management method provided in this application. Figure 1 As shown, the method includes the following: Step 101: Monitor the terminal's operating status through the terminal control module and report the status data to the management control module through the multi-channel control protocol.

[0035] The terminal control module refers to the functional module in the system that is specifically responsible for interacting with the terminal, and is responsible for communicating with the terminal's ADB service, automated testing tools (AutomatorX, ATX) service, etc.

[0036] It should be noted that in this step, the terminal control module collects the connection status and health status of the terminal in real time through the underlying ADB service and ATX service, and then encapsulates the collected status data according to the format of the multi-channel control protocol before reporting it to the management control module, providing data basis for subsequent anomaly judgment.

[0037] Step 102: Monitor the network status of the routing device through the network control module, and report the status data to the management control module through the multi-channel control protocol.

[0038] Among them, the network control module refers to the functional module in the system that is specifically responsible for interacting with the routing device.

[0039] It should be noted that in this step, the network control module establishes a mapping relationship between the routing device and its associated terminal based on the device serial number. By querying the network connection status of the terminal and performing network connectivity tests on the terminal side, the operating status of the routing device is comprehensively determined, and the determination result is reported to the management control module through the multi-channel control protocol.

[0040] Step 103: Monitor the status of the SIM card through the user identification module and the SIM card control module, and report the status data to the management control module through the multi-channel control protocol.

[0041] The SIM card control module refers to the functional module in the system that is specifically responsible for managing the SIM card and interacts with the microcontroller of the SIM card slot and the ATX service of the terminal.

[0042] It should be noted that in this step, the SIM card control module obtains the physical status of the SIM card slot by interacting with the microcontroller service of the SIM card slot, and at the same time queries the logical registration status of the SIM card in the mobile network through the terminal's ATX service. After combining the two pieces of information, the module reports them to the management control module through the multi-channel control protocol.

[0043] Step 104: The management and control module determines whether the monitored device is malfunctioning based on the received status data.

[0044] The management and control module refers to the central control unit of the system, which is responsible for receiving status data reported by each functional control module, running decision-making algorithms, and issuing control commands when necessary.

[0045] It should be noted that the management and control module has preset normal status thresholds and rule bases for various devices. When it receives reported status data, the management and control module parses the multi-channel control protocol data packets, extracts the status values, and compares them with preset rules. If the status value falls within the abnormal range, the device is determined to be abnormal.

[0046] Step 105: If an anomaly is detected, the management control module sends a control command to the function control module that reports the status data through the multi-channel control protocol. The multi-channel control protocol is used for data interaction between the management control module, the terminal control module, the network control module, and the SIM card control module.

[0047] Among them, the functional control module generally refers to the terminal control module, network control module, and SIM card control module.

[0048] It should be noted that in this step, once a device malfunction is detected, the management control module immediately generates corresponding control commands, encapsulates them according to the multi-channel control protocol format, and sends them to the functional control module that initially reported the malfunction. This functional control module then parses the commands and executes the specific operations, automatically restoring the device to normal operation, thus achieving closed-loop control from malfunction detection to automatic recovery.

[0049] This application incorporates three types of devices—terminals, networks, and SIM cards—into a unified management system through a custom multi-channel control protocol, enabling centralized status monitoring and automatic anomaly recovery, significantly improving the efficiency of multi-device collaborative management and system reliability.

[0050] Figure 2 This is an architecture diagram of the multi-device test control and management method provided in the embodiments of this application. For example... Figure 2 As shown, the multi-device test control and management method is applied to three functional modules and a management control module. The three functional modules are the terminal / mobile phone control module, the network control module, and the SIM card control module. The three functional modules and the management control module interact with each other through a multi-channel control protocol.

[0051] In some embodiments, the data packets of the multichannel control protocol include: The module type field is used to identify the terminal control module, network control module, or SIM card control module; The device serial number field, combined with the module type field, is used to uniquely identify each monitored physical device in the multi-device test control and management system.

[0052] The module type field is a fixed-length field in the multi-channel control protocol data packet, occupying 1 byte, used to identify the functional module type to which the data packet belongs. For example, 0x4D represents a terminal control module, 0x4F represents a network control module, and 0x53 represents a SIM card control module. The device serial number field is a fixed-length field in the multi-channel control protocol data packet, occupying 2 bytes, used to uniquely identify a specific physical device within the same module type. For example, 0x0001 represents mobile phone 1, and 0x0102 represents router 2.

[0053] It's important to note that in scenarios involving multi-device collaborative management, the core technical challenge lies in uniquely distinguishing and addressing different types of physical devices within a single system. This embodiment addresses this challenge through a composite identification mechanism of "module type + device serial number." The module type field distinguishes the broad category of the device (whether it's a mobile phone, router, or SIM card), while the device serial number field distinguishes the specific individual device within that category (which mobile phone or router). Together, they form a globally unique device identifier, enabling the management and control module to accurately locate any physical device when issuing commands or parsing reported data, regardless of device type or quantity. This design avoids the cumbersome process of designing separate addressing schemes for each device type, achieving unified addressing for heterogeneous devices.

[0054] This embodiment achieves unified addressing and precise positioning of heterogeneous devices such as mobile phones, routers, and SIM cards under a single protocol framework through the combined design of module type field and device serial number field, laying the foundation for collaborative management and control of multiple devices.

[0055] In some embodiments, the data packets of the multichannel control protocol further include at least one of the following fields: The packet type field is used to distinguish between request packets and response packets; The protocol type field is used to distinguish between status detection functions and power control functions; The data length field indicates the length in bytes of the data content field; The data content field is used to carry status information or control commands; The verification field is used to perform integrity checks on data packets. The end identifier field is used to indicate the end of the data packet.

[0056] The multi-channel control protocol data packet includes the following fields: Packet Type Field: A fixed-length field occupying 1 byte, used to distinguish the transmission direction of the data packet. For example, 0x53 represents a request packet (S packet) sent by the sender, and 0x52 represents a response packet (R packet) returned by the receiver. Protocol Type Field: A fixed-length field occupying 1 byte, used to identify the function type of this communication. For example, 0x45 represents status detection function, 0x4E represents power control function, and 0x53 represents data interaction function. Data Length Field: A fixed-length field occupying 2 bytes, used to indicate the actual byte length of the following data content field. If the data content is empty, the value is 0x0000. Data Content Field: A variable-length field occupying N bytes (N is determined by the data length field), used to carry specific status information or control commands, such as query commands 0x00 / 0x01, power control commands 0x00 / 0x01 / 0x02, and status return values ​​0x10 / 0x11. Checksum Field: A fixed-length field in the multichannel control protocol data packet, occupying 1 byte. Its value is the result of an XOR operation on all bytes of the module type field, device serial number field, data length field, data content field, and packet sequence number field. It is used to check whether errors have occurred in the data packet during transmission. End Identifier Field: A fixed field at the end of the multichannel control protocol data packet, occupying 5 bytes. Its value is 5 consecutive 0x0D characters. It is used to mark the end of a complete data packet, facilitating data frame segmentation and identification by the receiving end.

[0057] It should be noted that, to meet the complex and diverse communication needs in multi-device collaborative management scenarios, this embodiment further expands the structure definition of protocol data packets based on the core "module type + device serial number" identification mechanism. The packet type field enables bidirectional interaction between requests and responses, allowing reliable question-and-answer communication between the management control module and the functional control module. The protocol type field categorizes functions into status detection and power control, facilitating the receiving end to quickly determine the purpose of the data packet and distribute it to the corresponding processing logic. The data length field, in conjunction with the data content field, supports both fixed-length simple instructions and variable-length data transmission carrying complex parameters, enhancing the protocol's flexibility. The checksum field provides lightweight error detection capabilities through XOR operations, ensuring the integrity of control instructions and status data during transmission. The end identifier field solves the problem of data frame boundary identification, especially in physical layer transmissions such as serial ports that are byte-stream oriented, effectively avoiding packet fragmentation and incomplete packet issues. These fields together constitute a fully functional, robust, and reliable communication protocol, providing underlying communication assurance for 24 / 7 uninterrupted automated testing scenarios.

[0058] This embodiment expands the field definitions of the multi-channel control protocol to achieve bidirectional interaction, function classification, variable length transmission, error detection, and frame boundary recognition, significantly improving the applicability and reliability of the protocol in complex industrial control scenarios.

[0059] Figure 3 This is a schematic diagram illustrating the multi-channel control protocol format definition provided in an embodiment of this application. For example... Figure 3 As shown, to overcome the protocol barriers in the collaborative management of multiple devices and modules, a multi-channel control protocol (MCCP) was independently developed. Through structured design, it achieves efficient transmission and accurate parsing of commands. Its core features are as follows: Packet type (1 byte): Used to distinguish between sending and receiving packet types. Here, sending a packet (S packet) is defined as 0x53, and receiving a packet (R packet) is defined as 0x52.

[0060] Protocol type (1 byte): Used to identify the type and function of the protocol. For example, status detection 0x45, power control 0x4E, data interaction 0x53.

[0061] Module type (1 byte): Used to identify the functional module to which the transmitted data packet belongs. For example, the mobile phone control module is 0x4D, the network control module is 0x4F, and the SIM card control module is 0x53.

[0062] Device serial number (2 bytes): Used to uniquely identify devices in the system. Numbering follows device numbering rules, such as 0x0001 for mobile phone 1, 0x0102 for router 2, 0x0303 for SIM card 3, etc. It uses a 2-byte hexadecimal value, with the most significant byte (highest byte) or least significant byte (lowest byte) order being uniformly agreed upon.

[0063] Data length (2 bytes): Indicates the length of the data content in bytes. If the data content is empty, this value is 0x0000.

[0064] Data content (N bytes, can be empty): Contains the actual information to be transmitted, which varies depending on the module type and device operation.

[0065] Packet sequence number (1 byte): Starting from 0x00, incrementing in the range of 0-255, and reset after overflow, used to identify the order of data packets.

[0066] XOR check (1 byte): This check is obtained by performing an XOR operation on all bytes of the module type, device number, data length, data content, and packet number, and is used to verify the integrity of the data packet.

[0067] End marker (5 bytes, fixed as 0x0D): five consecutive 0x0D characters serve as the end marker for the data packet.

[0068] For example, the data packet encapsulation process at the sending end includes: the sending end completes data packet encapsulation in four steps: "field filling - data processing - verification generation - end identifier" to ensure that the format is standardized. The specific sending process is as follows.

[0069] 1. Initialize the data packet structure, create an empty data packet buffer, and prepare to fill each field according to the protocol format.

[0070] 2. Fill in fixed fields: Protocol Type (1 byte): Write the corresponding identifier value according to the protocol type. Module Type (1 byte): Write the corresponding identifier value according to the module to which the sending device belongs. Device Sequence Number (2 bytes): Write a 2-byte hexadecimal value according to the device numbering rules. Packet Sequence Number (1 byte): Incrementing from 0x00, indicating the order of the current data packet.

[0071] 3. Process the data content, writing the actual transmitted data content (N bytes), which can be empty. Calculate the data length (2 bytes): Count the number of bytes in the statistical data content and write 2 bytes.

[0072] 4. Generate a checksum by performing an XOR check on all bytes of "Module Type + Device Serial Number + Data Length + Data Content + Packet Serial Number". The initial checksum is 0x00. Perform an XOR operation with each byte of the above fields in sequence, and write the final result as a 1-byte checksum.

[0073] 5. Add an end marker, padding the end of the data packet with a fixed 5-byte end: 0x0D 0x0D 0x0D 0x0D0x0D.

[0074] 6. Send data packets: Send the fully encapsulated data packets to the receiving end through the physical layer (such as serial port, network).

[0075] For example, the receiving end data packet parsing process includes: the receiving end parses the data through the process of "end detection - length verification - check value verification - data matching - service distribution", efficiently filtering invalid packets and accurately locating the target device and business logic. The following is the specific process of the receiving end.

[0076] 1. Receive data and detect the end of the data. Continuously receive byte streams and check in real time for five consecutive 0x0D end markers. If no end marker is detected, continue buffering data; if an end marker is detected, extract the complete data packet from the most recent valid start position to the end.

[0077] 2. Verify the validity of the data packet length. Check if the total length of the data packet meets the minimum requirement of the protocol, which is 14 bytes (1+1+1+2+2+0+1+1+5). If it is less than 14 bytes, it is determined to be an invalid packet, discarded, and the cache is reset.

[0078] 3. Extract fields and verify checksums. Extract the following fields in order: Module Type, Device Serial Number, Data Length, Data Content, Packet Serial Number, and XOR Checksum. Recalculate the XOR value for "Module Type + Device Serial Number + Data Length + Data Content + Packet Serial Number" and compare it with the extracted checksum. If they do not match, a transmission error is identified, and the data packet is discarded; if they match, proceed to the next step.

[0079] 4. Verify data length matching: Check if the extracted data length (2 bytes) matches the actual data content in bytes. If they do not match, it is determined to be a format error and discarded; if they match, the data packet format is confirmed to be valid.

[0080] 5. Parse and process valid data, and distribute it to the corresponding processing module according to the module type. Locate the target device based on the device serial number, and execute specific business logic based on the data content. Record the packet sequence number to determine if there is packet loss or out-of-order delivery (used in conjunction with a retransmission mechanism).

[0081] In some embodiments, the method further includes: the function control module feeding back the execution result of the control command to the management control module through the multi-channel control protocol.

[0082] The execution result refers to the outcome generated by the functional control module after receiving the control command from the management control module and performing the corresponding operation. It typically includes two states: success or failure. For example, in a power control scenario, 0x00 represents a successful restart command execution, while 0x01 represents execution failure.

[0083] It should be noted that in automated testing and remote control scenarios, issuing commands without confirming execution results can lead to the management control module being unable to perceive the true status of the device, resulting in "blind operation." For example, if the management control module issues a restart command but fails to actually execute due to hardware failure, communication interruption, or incorrect command format, the management control module may mistakenly believe the device has recovered. Subsequent testing tasks will continue to be executed on the faulty device, causing distorted test results or even device damage. This embodiment improves the final link of closed-loop control by introducing an execution result feedback mechanism. After executing the control command, the functional control module immediately encapsulates the execution result (success / failure) into a response data packet according to the format of the multi-channel control protocol and returns it to the management control module through a packet type field (such as 0x52 to identify the response packet). Upon receiving the feedback, the management control module can confirm whether the command was executed correctly. If it receives failure feedback or fails to receive feedback within a timeout period, it can trigger a retry, alarm, or switch to a backup recovery strategy, thereby ensuring that every control operation is traceable and verifiable.

[0084] This embodiment feeds back the execution results of control commands to the management control module, forming a complete "monitoring-judgment-control-confirmation" closed loop. This avoids the risk of "blind operation" in remote control and significantly improves the reliability and traceability of the system.

[0085] In some embodiments, each functional module implements a closed-loop management of "status monitoring - anomaly judgment - control execution - result feedback" through the MCCP protocol.

[0086] Furthermore, the monitoring of the terminal's operating status via the terminal control module includes: The connection status of the terminal is monitored through the Android Debug Bridge (ADB) service, and the connection status includes at least one of online, offline, and unauthenticated. The terminal's operating status is monitored by the ATX service, which includes at least one of the following: normal, frozen, insufficient storage space, low battery, high temperature, and ATX service abnormality.

[0087] Among them, Android Debug Bridge (ADB) is an official Android debugging tool used to connect a personal computer to an Android device to perform operations such as device management, command sending, and file transfer. ATX Service is a background service program running on the mobile terminal, used to support remote control and status queries. The terminal control module can obtain information such as the phone's operating status (e.g., battery level, CPU load) and SIM card registration status by interacting with this service.

[0088] It should be noted that the Mobile Control Module (MCM), as the core of the mobile terminal's management, interacts with the mobile Adb and Atx services to achieve real-time monitoring of the mobile Adb connection status (online / offline / unauthenticated, etc.) and operating status (battery power / CPU load / storage space, etc.). It also supports remote intervention on abnormal mobile phones through power control commands (power off / power on / reboot), and the command execution results are fed back to the management system in real time.

[0089] Figure 4 This is a flowchart of the terminal control module provided in an embodiment of this application. For example... Figure 4 As shown, the terminal control module monitors the mobile phone status: first, it defines the mobile phone ADB connection status as 0x00 and the mobile phone's own status as 0x01.

[0090] Mobile ADB connection status definitions: 0x00: Device online, 0x01: Offline, 0x02: Unauthorized, 0x03: Unknown (Device lost).

[0091] Phone status: 0x10: Normal, 0x11: Phone frozen, 0x12: Phone SD card lost, 0x13: Insufficient phone storage space, 0x14: Phone battery too low, 0x15: Phone CPU too high, 0x16: Phone temperature too high, 0x17: Insufficient phone memory, 0x18: Phone ATX service abnormal, 0x19: Unknown abnormality.

[0092] Next, the MCCP protocol format for the sending end is defined as shown in Table 1 below.

[0093] Table 1. MCCP Protocol Format for Sender Package type Protocol type Module type Equipment serial number Data length Data content Package number XOR check End marker 0x53 0x45 0x4D 0x0001 0x0001 0x00 / 0x01 0x00 0x00 0x0D0D0D0D0D The management and control system sends data to the mobile control module via the MCCP protocol. The mobile control module receives the MCCP protocol data. If the data content is 0x00 querying the mobile phone's ADB connection status, the mobile control module will interact with the ADB service to query the mobile phone's connection status and encapsulate the result into the MCCP protocol format to notify the mobile control module. The returned content format is shown in Table 2 below.

[0094] Table 2. Format of ADB connection status return content Package type Protocol type Module type Equipment serial number Data length Data content Package number XOR check End marker 0x52 0x45 0x4D 0x0001 0x0001 0x00 0x00 0x00 0x0D0D0D0D0D If the data content is "0x01 querying phone status", the phone control module will interact with the Atx service to query the phone status and encapsulate the result into the MCCP protocol format to notify the phone control module. The returned content format is shown in Table 3 below.

[0095] Table 3. Format of Mobile Phone Operating Status Returns Package type Protocol type Module type Equipment serial number Data length Data content Package number XOR check End marker 0x52 0x45 0x4D 0x0001 0x0001 0x10 0x00 0x00 0x0D0D0D0D0D Power control: First, define the data content in the MCCP protocol: 0x00: power off, 0x01: power on, 0x02: reboot.

[0096] When the management and control system detects an abnormality in the mobile phone and needs to power off and restart it, the management and control system notifies the mobile phone control module through the MCCP protocol, as shown in Table 4 below.

[0097] Table 4 Power Control Command MCCP Protocol Format Package type Protocol type Module type Equipment serial number Data length Data content Package number XOR check End marker 0x53 0x4E 0x4D 0x0001 0x0001 0x02 0x00 0x00 0x0D0D0D0D0D The mobile phone control module receives the MCCP protocol, matches the device serial number in the MCCP protocol with the corresponding power module microcontroller serial port number, executes the restart command, and realizes the mobile phone power-off restart. It then returns the execution result via the MCCP protocol, filling the data content with 0x00 for success and 0x01 for failure. The return content format is shown in Table 5 below.

[0098] Table 5. Format of Power Control Results Return Package type Protocol type Module type Equipment serial number Data length Data content Package number XOR check End marker 0x52 0x4E 0x4D 0x0001 0x0001 0x00 / 0x01 0x00 0x00 0x0D0D0D0D0D This embodiment achieves comprehensive monitoring and automatic recovery of the connection and operation status of mobile terminals by deeply integrating the mobile control module with ADB and ATX services, combined with the refined status coding and closed-loop control process defined by the MCCP protocol. This significantly improves the system reliability and unattended operation capability in multi-device parallel testing scenarios.

[0099] In some embodiments, monitoring the network status of the routing device via the network control module includes: Match the terminal associated with the network control module based on the device serial number; The operating status of the routing device is determined by querying the network connection status of the terminal and by performing a network PING test on the terminal side. The operating status of the routing device includes at least one of the following: normal, terminal connection to the route failed, and terminal connected to the route but had no network access.

[0100] Among them, the PING test is a network connectivity test method that determines whether the network connection is smooth by sending data packets to the target server and waiting for a response.

[0101] It should be noted that the Network Control Module (NCM) focuses on the network status management of routing devices. By matching the corresponding mobile terminal with the routing device serial number, and combining the mobile network connection status and PING test results, it accurately determines the operating status of the router (normal / connection failure / no network, etc.). For abnormal routers, a restart command can be issued and a power-off restart can be performed through the power module to ensure network access stability.

[0102] Figure 5 This is a flowchart illustrating the network control module provided in an embodiment of this application. Figure 5 As shown, the route status monitoring is as follows: First, the route status is defined as follows: 0x00: the route is normal, 0x01: the mobile phone failed to connect to the route, 0x02: the mobile phone has no network when connected to the route, and 0x03: Unknown.

[0103] Next, the MCCP protocol format for the sending end is defined as shown in Table 6 below.

[0104] Table 6. MCCP Protocol Format 2 for the Sending End Package type Protocol type Module type Equipment serial number Data length Data content Package number XOR check End marker 0x53 0x45 0x4F 0x0102 0x0001 0x00 0x00 0x00 0x0D0D0D0D0D The management and control system sends data to the network control module via the MCCP protocol. The network control module receives the MCCP protocol data, matches the corresponding mobile phone using the device serial number of the router, checks the network status of the mobile phone to determine the connection status between the mobile phone and the router, and performs a PING test on the mobile phone to determine the network status of the router. The results are then encapsulated in the MCCP protocol format and sent to the network control module. The returned content format is shown in Table 7 below.

[0105] Table 7. Format of Route Status Return Content Package type Protocol type Module type Equipment serial number Data length Data content Package number XOR check End marker 0x52 0x45 0x4F 0x0102 0x0001 0x00 0x00 0x00 0x0D0D0D0D0D Power control: First, define the data content in the MCCP protocol: 0x00: power off, 0x01: power on, 0x02: reboot.

[0106] When the management and control system detects a routing anomaly and needs to power off and restart the routing, the management and control system notifies the network control module through the MCCP protocol. The instruction format is shown in Table 8.

[0107] Table 8 Router power control command format Package type Protocol type Module type Equipment serial number Data length Data content Package number XOR check End marker 0x53 0x4E 0x4F 0x0102 0x0001 0x02 0x00 0x00 0x0D0D0D0D0D The network control module receives the MCCP protocol, matches the device serial number in the MCCP protocol with the corresponding power module microcontroller serial port number, executes the restart command, and realizes the router's power-off restart. It then returns the execution result via the MCCP protocol, filling the data content with 0x00 for success and 0x01 for failure. The return content format is shown in Table 9 below.

[0108] Table 9. Router Power Control Result Return Format Package type Protocol type Module type Equipment serial number Data length Data content Package number XOR check End marker 0x52 0x4E 0x4F 0x0102 0x0001 0x00 / 0x01 0x00 0x00 0x0D0D0D0D0D This embodiment achieves accurate judgment and automatic recovery of the network status of routing devices through the linkage monitoring mechanism between the network control module and the terminal side, combined with the routing status coding and closed-loop control process defined by the MCCP protocol, which significantly improves the network access stability and system reliability in multi-device testing scenarios.

[0109] In some embodiments, monitoring the status of the SIM card via the SIM card control module includes: By interacting with the microcontroller service of the SIM card slot, the physical state of the card slot is obtained, including at least one of idle, in use, and no card; The logical registration status of the SIM card is queried through the terminal's ATX service. The registration status includes at least one of normal, no card, and locked.

[0110] The microcontroller service runs on the SIM card slot control chip and manages the physical state of the SIM card slot, including whether it is idle, in use, or without a card. It communicates with the SIM card control module via a serial port. The physical state of the SIM card slot refers to its hardware status, including idle (IDEL, slot not in use), in use (Busy, slot currently occupied), and no card (NoCard, no SIM card in the slot). The logical registration status refers to the SIM card's registration status in the mobile communication network, including normal (READY, SIM card ready), no card (ABSENT, phone does not detect SIM card), and locked (LOCKED, SIM card locked by PIN code or network).

[0111] It should be noted that the SIM Card Control Module (SCM) enables fine-grained management of the SIM card. On the one hand, it interacts with the SIM card slot microcontroller service to obtain the card slot status (idle / in use / no card, etc.). On the other hand, it queries the SIM card registration status (normal / no card / locked, etc.) through the mobile phone's Atx service. When an abnormality of the SIM card is detected, a restart command can be triggered to complete the power-off reset of the SIM card through the power module.

[0112] Figure 6 This is a flowchart illustrating the SIM card control module provided in an embodiment of this application. Figure 6 As shown, SIM status monitoring: First, define SIM status 0x00 and mobile SIM registration status 0x01.

[0113] SIM card slot status definitions: 0x00: IDEL (Idle), 0x01: Busy (In Use), 0x02: No Card, 0x03: Unknown.

[0114] Mobile SIM card registration status: 0x10: READY (normal), 0x11: ABSENT (no card), 0x12: LOCKED, 0x13: Unknown exception.

[0115] Next, the MCCP protocol format for the sending end is defined as shown in Table 10 below.

[0116] Table 10 MCCP Protocol Format 3 for the Sending End Package type Protocol type Module type Equipment serial number Data length Data content Package number XOR check End marker 0x53 0x45 0x53 0x0303 0x0001 0x00 / 0x01 0x00 0x00 0x0D0D0D0D0D The management and control system sends data to the SIM card control module via the MCCP protocol. The SIM card control module receives the MCCP protocol data. If the data content is "0x00 Query SIM card slot status," the SIM card control module will interact with the SIM card slot module's microcontroller service. The SIM card slot module's microcontroller service will query the SIM status of the specified device serial number and encapsulate the result into the MCCP protocol format, notifying the SIM card control module of the result. The returned content format is shown in Table 11 below.

[0117] Table 11 SIM Card Slot Status Return Content Format Package type Protocol type Module type Equipment serial number Data length Data content Package number XOR check End marker 0x52 0x45 0x53 0x0303 0x0001 0x00 0x00 0x00 0x0D0D0D0D0D If the data content is 0x01 querying the phone status, the SIM control module will interact with the phone's Atx service to query the phone's SIM card registration status and encapsulate the result into the MCCP protocol format to notify the SIM card control module. The returned content format is shown in Table 12 below.

[0118] Table 12 Format of SIM Card Registration Status Return Content Package type Protocol type Module type Equipment serial number Data length Data content Package number XOR check End marker 0x52 0x45 0x53 0x0303 0x0001 0x10 0x00 0x00 0x0D0D0D0D0D Power control: First, define the data content in the MCCP protocol: 0x00: power off, 0x01: power on, 0x02: reboot.

[0119] When the management and control system detects an abnormality in the mobile phone SIM card and needs to power off and restart the SIM card, the management and control system notifies the SIM card control module through the MCCP protocol. The instruction format is shown in Table 13 below.

[0120] Table 13 SIM Card Power Control Command Format Package type Protocol type Module type Equipment serial number Data length Data content Package number XOR check End marker 0x53 0x4E 0x53 0x0303 0x0001 0x02 0x00 0x00 0x0D0D0D0D0D The SIM card control module receives the MCCP protocol, matches the device serial number in the MCCP protocol with the corresponding power module microcontroller serial port number, executes the restart command, and realizes the SIM card power-off restart. It then returns the execution result via the MCCP protocol, filling the data content with 0x00 for success and 0x01 for failure. The return content format is shown in Table 14 below.

[0121] Table 14 SIM Card Power Control Result Return Format Package type Protocol type Module type Equipment serial number Data length Data content Package number XOR check End marker 0x52 0x4E 0x53 0x0001 0x0001 0x00 / 0x01 0x00 0x00 0x0D0D0D0D0D This embodiment achieves comprehensive monitoring and automatic recovery of the physical and logical registration status of the SIM card through a dual interaction mechanism between the SIM card control module, the card slot microcontroller service, and the mobile phone ATX service, combined with the SIM card status coding and closed-loop control process defined by the MCCP protocol. This significantly improves the compatibility and system reliability of SIM card management in multi-brand mobile phone environments.

[0122] In some embodiments, the multi-device test control and management system further includes a power controller; the method further includes: The power controller provides controllable power output to the terminal, routing device, or SIM card slot. The control commands include power control commands; The function control module performs a power-off and restart operation on the abnormal physical device through the power controller according to the power control command.

[0123] In some embodiments, the method further includes: when a new type of device is connected, the management control module assigns a new module type field value to the new type of device and assigns a new device serial number to the specific physical device under that type; The management control module and each functional control module identify and manage the new type of device based on the module type field and the new device serial number.

[0124] Among them, "new type of device" refers to devices other than terminals (mobile phones), routing devices, and SIM cards, such as smart home devices, sensors, and industrial controllers, which are hardware devices that need to be included in the unified testing and management system. The module type field value is a coded value used in the multi-channel control protocol to identify the major category of the device, occupying 1 byte. For example, 0x4D represents a terminal control module, 0x4F represents a network control module, and 0x53 represents a SIM card control module. New module type field values ​​are assigned to new type of devices, that is, new values ​​are added to the existing coding, such as 0x5A representing a smart home device module. The device serial number is a coded value used in the multi-channel control protocol to uniquely identify a specific physical device within the same device type, occupying 2 bytes. For example, 0x0001 represents the first device of this type. New device serial numbers are assigned to new type of devices, that is, a unique serial number is assigned to each physical device within this type according to the numbering rules.

[0125] It should be noted that in the practical application of a multi-device test control and management system, testing requirements are dynamically changing, and in the future, it may be necessary to uniformly manage other types of devices besides mobile phones, routers, and SIM cards. This embodiment provides support for the flexible expansion of the system through the composite identification mechanism of "module type + device serial number" in the MCCP protocol.

[0126] Specifically, when a new type of device needs to be connected, a new module type field value is simply assigned to this new device type in the protocol definition, and a unique device serial number is assigned to each specific physical device under this type. The management control module and each functional control module still rely on the original protocol parsing logic, identifying the major category of the device by recognizing the module type field and locating the specific physical device by the device serial number field, without modifying the core code or protocol architecture.

[0127] This embodiment achieves "plug-and-play" flexible expansion of new types of devices through the collaborative design of the module type field and the device serial number field. Any new device can be incorporated into the unified management and control system without reconstructing the protocol architecture, which significantly reduces the integration cost of multiple devices and the complexity of system maintenance.

[0128] The multi-device test control and management method provided in this application, through hardware collaboration and intelligent design, achieves efficient, accurate, and automated APP testing, balancing efficiency and scenario realism. Furthermore, it customizes the MCCP protocol and closed-loop control mechanism, enabling a leap from "distributed management" to "collaborative control" and from "passive monitoring" to "proactive self-healing" for multiple devices, providing an efficient and flexible technical solution for unified management of heterogeneous devices.

[0129] The innovative aspects of the multi-device test control and management method provided in this application are as follows: 1. Protocol innovation for unified management of multiple devices: The pioneering MCCP protocol solves the problems of redundancy in traditional general protocols and poor compatibility of private protocols through a three-dimensional identification mechanism of "protocol type + module type + device serial number", realizing unified protocol management of mobile phones, routers and SIM cards across devices, filling a gap in the industry.

[0130] 2. Modular architecture expansion innovation: Through the collaborative design of module type and device serial number, new devices only need to define a unique serial number and module identifier to be connected to the system without reconstructing the architecture, realizing "plug and play" elastic expansion and significantly reducing the integration cost of multiple devices.

[0131] 3. Intelligent innovation of closed-loop control: Deeply linking granular status monitoring with precise control commands to form a fault self-healing mechanism of "automatic anomaly identification - automatic command issuance - automatic result verification", which significantly improves equipment reliability and management efficiency compared with the traditional manual intervention mode.

[0132] The multi-device test control and management method provided in this application has the following technical advantages over the prior art.

[0133] 1. Unified management of multiple devices breaks down barriers between heterogeneous devices.

[0134] The system utilizes three core modules—Mobile Control Module (MCM), Network Control Module (NCM), and SIM Card Control Module (SCM)—to centrally manage three types of heterogeneous hardware: mobile phones, routers, and SIM cards. While these three types of devices have significantly different functions (e.g., mobile phones focus on terminal status, routers on network access, and SIM cards on communication authentication), the system integrates these disparate device management processes into a unified system through a unified interaction logic (a closed-loop "monitor-judgment-control" process) and protocol specifications. This avoids the fragmentation problems inherent in traditional single-device management methods.

[0135] 2. Modular architecture design, balancing professionalism and collaboration.

[0136] Each control module has a clear division of labor and works in concert: Specialization: MCM focuses on monitoring and controlling the ADB connection status and operational status (such as battery level and CPU load) of mobile terminals; NCM focuses on managing the network connection status of routers (such as mobile phone network failure and no network); SCM provides fine-grained control over the SIM card slot status (idle / in use / no card) and registration status (normal / no card / locked). Each module is adapted to the hardware characteristics and interaction requirements of the corresponding device (such as MCM interacting with ADB / ATX services, and SCM interacting with the SIM card slot microcontroller services).

[0137] Collaboration: All modules communicate with the management and control system based on the MCCP protocol. The "Module Type" field (0x4D / 0x4F / 0x53) enables precise distribution of instructions, ensuring the orderly operation of multiple modules in parallel.

[0138] 3. The MCCP protocol is standardized and flexible, adapting to various scenario requirements.

[0139] The custom multichannel control protocol (MCCP) is the core support of the system, and its design embodies the characteristic of "seeking flexibility within specifications": The standard structure definition includes fields such as packet type (transmit / receive distinction), protocol type (functional distinction: 0x45 status detection / 0x4E power control), module type (device type distinction), device serial number (unique identifier), and verification mechanism (XOR check) to ensure the integrity (verification field) and identifiability (frame header / frame trailer) of data transmission.

[0140] Flexible scalability: Through the dynamic definition of the "Data Content" field (e.g., 0x00 / 0x01 distinguishes different query types, 0x00 / 0x01 / 0x02 distinguishes power on / off / reboot commands), it can adapt to the diverse needs of different devices; the "Device Serial Number" adopts 2-byte hexadecimal encoding (e.g., 0x0001 represents mobile phone 1, 0x0102 represents router 2), supporting the system to access more device types without modifying the overall protocol structure.

[0141] 4. Refined condition monitoring and closed-loop control ensure equipment reliability.

[0142] The system monitors the status of various devices across all dimensions, including "basic connectivity, operational status, and anomaly alarms," ​​and links control functions to form a closed loop. Granular status definitions: For example, mobile phone status is subdivided into 10 types (0x10 Normal to 0x19 Unknown Abnormal), covering multiple dimensions such as hardware (battery, storage space), software (ATX service abnormality), and resources (CPU / memory too high); routing status distinguishes between "connection failure" and "connection but no network", accurately locating network fault points.

[0143] Real-time control response: When an anomaly is detected (such as a frozen phone, no network on the router, or no SIM card registration), the management system issues control commands (such as 0x02 Restart) through the MCCP protocol. Each module executes the commands precisely by matching the device serial number with the power module serial port number and returns the execution result (0x00 Success / 0x01 Failure), forming a complete closed loop of "monitoring-judgment-control-feedback".

[0144] The multi-device test control and management system provided in this application is described below. The multi-device test control and management system described below can be referred to in correspondence with the multi-device test control and management method described above.

[0145] Figure 7 This is a schematic diagram of the structure of the multi-device test control and management system provided in an embodiment of this application. For example... Figure 7 As shown, the multi-device test control and management system includes: a management control module 710; and Multiple functional control modules are respectively connected to the management control module; the multiple functional control modules include at least a terminal control module 720, a network control module 730, and a SIM card control module 740. The management control module 710 interacts with each functional control module via a multi-channel control protocol. The terminal control module 720 is used to monitor the operating status of the terminal and report the status data to the management control module through the multi-channel control protocol; The network control module 730 is used to monitor the network status of the routing device and report the status data to the management control module through the multi-channel control protocol. The SIM card control module 740 is used to monitor the status of the SIM card and report the status data to the management control module through the multi-channel control protocol. The management control module 710 is used to determine whether the monitored device has malfunctioned based on the received status data. If an malfunction is determined, a control command is sent to the function control module that reports the status data through the multi-channel control protocol.

[0146] It should be noted that the multi-device test control and management system provided in this application adopts a modular and layered architecture design. The management control module 710, as the central decision-making unit of the system, is responsible for global status aggregation and anomaly judgment; the terminal control module 720, network control module 730, and SIM card control module 740, as functional execution units, respectively connect to different types of controlled devices and undertake status acquisition and control execution tasks in their respective domains.

[0147] Each functional control module interacts with the controlled device through device-specific interface protocols: the terminal control module 720 communicates with the mobile terminal through ADB and ATX services to monitor the connection and operation status of the mobile phone; the network control module 730 associates the mobile terminal with the device serial number and judges the network status of the routing device by combining the mobile phone network connection status and PING test results; the SIM card control module 740 obtains the physical status and logical registration status of the SIM card slot by interacting with the card slot microcontroller service and the mobile phone ATX service.

[0148] The management control module 710 communicates with each functional control module via a customized multi-channel control protocol (MCCP). This protocol employs a composite identification mechanism of "module type + device serial number" to ensure that commands and data are accurately routed to the target device and functional module. When any functional control module reports status data indicating a device malfunction, the management control module 710 immediately generates a corresponding control command (such as a restart command) and sends it to the functional control module that initially reported the malfunction via the MCCP protocol. That module then performs the specific recovery operation, forming a complete closed-loop control process.

[0149] This embodiment achieves unified monitoring and closed-loop control of three types of heterogeneous devices—mobile phones, routers, and SIM cards—through a collaborative architecture of the management control module and the three major functional control modules, combined with standardized communication of multi-channel control protocols. This significantly improves the efficiency of multi-device collaborative management and system reliability.

[0150] In some embodiments, the data packets of the multichannel control protocol include: The module type field is used to identify the terminal control module, network control module, or SIM card control module; The device serial number field, combined with the module type field, is used to uniquely identify each monitored physical device in the multi-device test control and management system.

[0151] In some embodiments, the data packets of the multichannel control protocol further include at least one of the following fields: The packet type field is used to distinguish between request packets and response packets; The protocol type field is used to distinguish between status detection functions and power control functions; The data length field indicates the length in bytes of the data content field; The data content field is used to carry status information or control commands; The verification field is used to perform integrity checks on data packets. The end identifier field is used to indicate the end of the data packet.

[0152] In some embodiments, the function control module is further configured to feed back the execution result of the control command to the management control module through the multi-channel control protocol.

[0153] In some embodiments, the terminal control module monitors the terminal's operating status by including: The connection status of the terminal is monitored through the Android Debug Bridge (ADB) service, and the connection status includes at least one of online, offline, and unauthenticated. The terminal's operating status is monitored by the ATX service, which includes at least one of the following: normal, frozen, insufficient storage space, low battery, high temperature, and ATX service abnormality.

[0154] In some embodiments, the network control module monitors the network status of the routing device, including: Match the terminal associated with the network control module based on the device serial number; The operating status of the routing device is determined by querying the network connection status of the terminal and by performing a network PING test on the terminal side. The operating status of the routing device includes at least one of the following: normal, terminal connection to the route failed, and terminal connected to the route but had no network access.

[0155] In some embodiments, the SIM card control module monitors the status of the SIM card by including: By interacting with the microcontroller service of the SIM card slot, the physical state of the card slot is obtained, including at least one of idle, in use, and no card; The logical registration status of the SIM card is queried through the terminal's ATX service. The registration status includes at least one of normal, no card, and locked.

[0156] In some embodiments, the system further includes a power controller; The power controller is used to provide controllable power output to the terminal, routing device, or SIM card slot; The control commands include power control commands; The function control module performs a power-off and restart operation on the abnormal physical device through the power controller according to the power control command.

[0157] In some embodiments, when a new type of device is connected, the management control module is used to assign a new module type field value to the new type of device and assign a new device serial number to the specific physical device under that type; The management control module and each functional control module identify and manage the new type of device based on the module type field and the new device serial number.

[0158] Figure 8 This is a schematic diagram of the hardware structure of the multi-device test control and management system provided in an embodiment of this application. Figure 8 As shown, in the APP testing system, the various functional modules work together to ensure the efficient and accurate execution of testing tasks.

[0159] Figure 9 This is a module architecture diagram of the multi-device test control and management system provided in this application embodiment. For example... Figure 9 The diagram illustrates the relationships between the various modules. The following sections will provide a detailed explanation of each functional module.

[0160] Terminal (Mobile Phone): The terminal supports APP service testing (browsing, video, games, etc.) and 5G new service testing (5G messaging, VoNR, multimedia ringback tones). The terminal communicates with the terminal control module through a standardized interface and is equipped with a customized testing system. This patented product can support connecting multiple terminal devices through an extended USB-HUB.

[0161] Terminal Control Module: The core components of the terminal control module include a task scheduling module (based on a priority queue algorithm), a power management module (supporting serial port command power on / off), a routing control module (Wi-Fi 6 protocol configuration), and a SIM card access module (external SIM card slot link establishment). The terminal control module achieves multi-device status monitoring (battery power, network) through the ATX-Agent unified interface and uses WebSocket to synchronize screen mirroring in real time.

[0162] Router: Provides broadband access for three major networks, meeting the network bandwidth and stability requirements of APP testing.

[0163] Power Controller: The power controller integrates a power control chip and receives power on / off commands via the ttyACM serial port to control the device module to power off and restart.

[0164] Graphics card: By migrating OpenCV image recognition and RapidOCR text recognition to the GPU through the CUDA / OpenCL interface, the CPU load is reduced by more than 30%.

[0165] External SIM card slot: The pins of the mobile phone's SIM card slot are connected to the external card slot through hardware circuitry, supporting remote virtual card access (AT commands are sent via the ttyACM serial port).

[0166] It should be noted that the multi-device test control and management system encountered the following two main problems during its development: High hardware complexity: The product integrates multiple hardware modules, including terminals (multiple mobile phones), terminal control modules, routers, power controllers, graphics cards, and external SIM card slots. The interface protocols, data formats, and working logic of each module differ significantly, posing multiple challenges to unified management and collaborative operation. Equipment stability: Fault prevention under long-term testing is a major challenge. The product needs to support 24 / 7 uninterrupted testing, but modules are prone to failure or anomalies under high load. Achieving real-time monitoring and rapid recovery became the core challenge of the development.

[0167] In view of the above problems, this application proposes a custom MCCP multi-channel control protocol and a converged device management method. It realizes integrated management and control of three types of heterogeneous devices, namely mobile phones, routers and SIM cards, through three core control modules, and achieves comprehensive management of devices through the MCCP multi-channel control protocol, breaking the fragmented limitations of traditional single device management.

[0168] The multi-device test control and management system has the following advantages: 1. Parallel testing with multiple devices significantly improves testing efficiency.

[0169] The terminal supports multiple device connections via a Universal Serial Bus Hub (USB-HUB). Combined with the terminal control module's task scheduling module (based on a priority queue algorithm), it can simultaneously perform automated testing on mobile phones of different brands, models, and system versions. For example, it can simultaneously test the compatibility of an app on multiple different device models without requiring sequential queuing, directly increasing testing efficiency several times over. This is particularly suitable for large-scale regression testing or multi-version parallel testing scenarios.

[0170] 2. It has strong network environment adaptability and closely matches real user scenarios.

[0171] The routing module supports broadband access from all three major Chinese mobile networks (China Mobile, China Unicom, and China Telecom), simulating different network environments to test the stability of app network interactions under specific carriers. Simultaneously, the data network testing capabilities supported by the mobile terminal after inserting a SIM card cover complex network scenarios such as "data network + Wi-Fi," making test results closer to real-world user environments and reducing blind spots caused by a single network environment.

[0172] 3. It flexibly supports complex testing scenarios, covering the needs of various types of apps.

[0173] The terminal supports diverse testing scenarios: it not only covers the testing of regular APP services such as browsing, video, and games, but also supports new 5G services (5G messaging, Voice over New Radio (VoNR), and multimedia ringback tones), which can meet the specific testing needs of various types of APPs such as social networking, entertainment, and communication.

[0174] The task scheduling priority mechanism can adapt to complex testing processes: for example, in batch testing, core function test tasks are executed first, and then peripheral functions are processed to ensure that key scenarios are verified first and optimize the allocation of test resources.

[0175] 4. AI recognition speeds up script execution, improving efficiency and accuracy.

[0176] The graphics card module migrates OpenCV image recognition (such as UI element localization) and RapidOCR text recognition (such as CAPTCHA and pop-up text recognition) to the GPU via the CUDA / OpenCL interface, reducing CPU load by more than 30%. In automated testing, UI element recognition and text verification are core components. GPU acceleration can significantly improve recognition speed (e.g., from 0.5 seconds / test to 0.2 seconds / test), while reducing recognition latency or errors caused by excessive CPU load, making test scripts execute more smoothly and results more reliable.

[0177] 5. End-to-end remote automated control reduces human intervention.

[0178] Equipment control automation: The power management module (serial port command power on / off) of the terminal control module works in conjunction with the power controller (remote power off / restart) to automatically handle problems such as equipment freezing and unresponsiveness during testing (e.g., remotely restarting the equipment) without the need for manual power plugging / unplugging or equipment operation.

[0179] SIM card operation automation: The external SIM card slot connects to the phone pins via hardware circuitry, supporting remote virtual card access (AT commands sent via ttyACM serial port). It can automatically switch between SIM cards from different operators and plans, and test the performance of apps under different network standards (such as 5G / 4G) and different operator environments (such as 5G message sending and VoNR calls), avoiding the hassle of manually inserting and removing SIM cards.

[0180] Automated status monitoring: Monitor the status (battery, network) of multiple devices through the unified ATX-Agent interface, and combine WebSocket to synchronize screen mirroring in real time. The test process can be viewed remotely in real time without the need for manual monitoring of the device interface.

[0181] Figure 10 This is a schematic diagram of the physical structure of the electronic device provided in the embodiments of this application. For example... Figure 10 As shown, the electronic device may include: a processor 1010, a communications interface 1020, a memory 1030, and a communication bus 1040, wherein the processor 1010, the communications interface 1020, and the memory 1030 communicate with each other via the communication bus 1040. The processor 1010 can call logical instructions in the memory 1030 to execute a multi-device test control and management method, which includes: The terminal control module monitors the terminal's operating status and reports the status data to the management control module via a multi-channel control protocol. The network control module monitors the network status of the routing device and reports the status data to the management control module through the multi-channel control protocol. The SIM card status is monitored by the user identification module and the SIM card control module, and the status data is reported to the management control module through the multi-channel control protocol. The management and control module determines whether the monitored device is malfunctioning based on the received status data. If an anomaly is detected, the management control module sends a control command to the function control module that reports the status data via the multi-channel control protocol. The multi-channel control protocol is used for data interaction between the management control module, the terminal control module, the network control module, and the SIM card control module.

[0182] Furthermore, the logical instructions in the aforementioned memory 1030 can be implemented as software functional units and, when sold or used as independent products, 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 a 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 and includes several 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, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0183] On the other hand, this application also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer is able to execute the multi-device test control and management method provided by the above methods, the method including: The terminal control module monitors the terminal's operating status and reports the status data to the management control module via a multi-channel control protocol. The network control module monitors the network status of the routing device and reports the status data to the management control module through the multi-channel control protocol. The SIM card status is monitored by the user identification module and the SIM card control module, and the status data is reported to the management control module through the multi-channel control protocol. The management and control module determines whether the monitored device is malfunctioning based on the received status data. If an anomaly is detected, the management control module sends a control command to the function control module that reports the status data via the multi-channel control protocol. The multi-channel control protocol is used for data interaction between the management control module, the terminal control module, the network control module, and the SIM card control module.

[0184] In another aspect, this application also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the multi-device test control and management method provided by the methods described above, the method comprising: The terminal control module monitors the terminal's operating status and reports the status data to the management control module via a multi-channel control protocol. The network control module monitors the network status of the routing device and reports the status data to the management control module through the multi-channel control protocol. The SIM card status is monitored by the user identification module and the SIM card control module, and the status data is reported to the management control module through the multi-channel control protocol. The management and control module determines whether the monitored device is malfunctioning based on the received status data. If an anomaly is detected, the management control module sends a control command to the function control module that reports the status data via the multi-channel control protocol. The multi-channel control protocol is used for data interaction between the management control module, the terminal control module, the network control module, and the SIM card control module.

[0185] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0186] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0187] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A multi-device test control and management method, characterized in that, include: The terminal control module monitors the terminal's operating status and reports the status data to the management control module via a multi-channel control protocol. The network control module monitors the network status of the routing device and reports the status data to the management control module through the multi-channel control protocol. The SIM card status is monitored by the user identification module and the SIM card control module, and the status data is reported to the management control module through the multi-channel control protocol. The management and control module determines whether the monitored device is malfunctioning based on the received status data. If an anomaly is detected, the management control module sends a control command to the function control module that reports the status data via the multi-channel control protocol. The multi-channel control protocol is used for data interaction between the management control module, the terminal control module, the network control module, and the SIM card control module.

2. The multi-device test control and management method according to claim 1, characterized in that, The data packets of the multi-channel control protocol include: The module type field is used to identify the terminal control module, network control module, or SIM card control module; The device serial number field, combined with the module type field, is used to uniquely identify each monitored physical device in the multi-device test control and management system.

3. The multi-device test control and management method according to claim 2, characterized in that, The data packets of the multichannel control protocol also include at least one of the following fields: The packet type field is used to distinguish between request packets and response packets; The protocol type field is used to distinguish between status detection functions and power control functions; The data length field indicates the length in bytes of the data content field; The data content field is used to carry status information or control commands; The verification field is used to perform integrity checks on data packets. The end identifier field is used to indicate the end of the data packet.

4. The multi-device test control and management method according to claim 1, characterized in that, Also includes: The function control module feeds back the execution result of the control command to the management control module through the multi-channel control protocol.

5. The multi-device test control and management method according to claim 1, characterized in that, The monitoring of the terminal's operating status via the terminal control module includes: The connection status of the terminal is monitored through the Android Debug Bridge (ADB) service, and the connection status includes at least one of online, offline, and unauthenticated. The terminal's operating status is monitored by the ATX service, which includes at least one of the following: normal, frozen, insufficient storage space, low battery, high temperature, and ATX service abnormality.

6. The multi-device test control and management method according to claim 1, characterized in that, The monitoring of the network status of the routing device via the network control module includes: Match the terminal associated with the network control module based on the device serial number; The operating status of the routing device is determined by querying the network connection status of the terminal and by performing a network PING test on the terminal side. The operating status of the routing device includes at least one of the following: normal, terminal connection to the route failed, and terminal connected to the route but had no network access.

7. The multi-device test control and management method according to claim 1, characterized in that, The monitoring of the SIM card status via the SIM card control module includes: By interacting with the microcontroller service of the SIM card slot, the physical state of the card slot is obtained, including at least one of idle, in use, and no card; The logical registration status of the SIM card is queried through the terminal's ATX service. The registration status includes at least one of normal, no card, and locked.

8. The multi-device test control and management method according to claim 1, characterized in that, The multi-device test control and management system further includes a power controller; the method further includes: The power controller provides controllable power output to the terminal, routing device, or SIM card slot. The control commands include power control commands; The function control module performs a power-off and restart operation on the abnormal physical device through the power controller according to the power control command.

9. The multi-device test control and management method according to claim 1, characterized in that, Also includes: When a new type of device is connected, the management and control module assigns a new module type field value to the new type of device and assigns a new device serial number to the specific physical device under that type; The management control module and each functional control module identify and manage the new type of device based on the module type field and the new device serial number.

10. A multi-device test control and management system, characterized in that, include: Management and control module; as well as Multiple functional control modules are communicatively connected to the management and control module; the multiple functional control modules include at least a terminal control module, a network control module, and a SIM card control module. The management control module and each functional control module interact with each other via a multi-channel control protocol. The terminal control module is used to monitor the operating status of the terminal and report the status data to the management control module through the multi-channel control protocol; The network control module is used to monitor the network status of the routing device and report the status data to the management control module through the multi-channel control protocol. The SIM card control module is used to monitor the status of the SIM card and report the status data to the management control module through the multi-channel control protocol. The management and control module is used to determine whether the monitored device has malfunctioned based on the received status data. If an malfunction is determined, a control command is sent to the function control module that reports the status data through the multi-channel control protocol.

11. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the multi-device test control and management method as described in any one of claims 1 to 9.

12. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the multi-device test control and management method as described in any one of claims 1 to 9.

13. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the multi-device test control and management method as described in any one of claims 1 to 9.

Images