Remote communication module master-slave state monitoring and switching system

Abstract

The application discloses a remote communication module master-slave state monitoring and switching system, relates to the technical field of remote upgrade management of embedded communication modules, and is used for solving the problems of flashing failure, system failure and parameter loss in the high-risk stage in the master-slave structure upgrade process; the system realizes controllable system partition switching and flashing scheduling by collecting the module running state and the flashing health degree index in the system running process and combining the master-slave structure. In the high-risk stage, the system intervenes in the flashing control process based on the minimum system boot mechanism. Meanwhile, the system automatically completes the backup and migration of the master-slave radio frequency parameter configuration, and avoids the network unavailability problem caused by the loss of communication parameters. After the upgrade is completed, the result return mechanism forms a full-link closed loop. The system has the characteristics of engineering deployability, small resource occupation, complete recovery mechanism and the like, and is suitable for the remote upgrade security guarantee scene of low-capacity embedded communication modules.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of embedded communication module remote upgrade management, more particularly, the present application relates to a remote communication module master-slave state monitoring and switching system. BACKGROUND

[0002] The communication module currently widely deployed in the Internet of Things, intelligent manufacturing, energy metering and other scenarios generally has remote upgrade (OTA) capability to support function expansion, vulnerability repair and long-term maintenance. However, in small-capacity embedded modules, there are many high-risk links in the remote upgrade process, especially during the master system partition flashing stage. Once the flashing interruption, power anomaly or data verification failure occurs, it may cause the system to fail to start, resulting in communication interruption or remote out-of-control serious consequences. To alleviate such problems, the traditional scheme generally uses a dual-system master-slave structure to ensure basic recoverability by alternately switching partitions before and after flashing. However, most of such structures rely on physical switching mechanisms controlled by bootflag, lack real-time monitoring and dynamic handling capabilities for flashing process risks, and cannot provide multi-path repair solutions when flashing anomalies occur. In addition, in some modules that rely on QCN (Qualcomm Calibration Network) radio frequency configuration files, if the migration of radio frequency parameters between master and slave partitions is not handled properly during flashing, the module may fail to register the network after flashing, causing degradation or interruption at the business level. Currently, there is still a lack of a closed-loop upgrade control system that can be deployed in a resource-constrained environment and has state monitoring, risk perception, minimal system intervention and radio frequency protection capabilities.

[0003] To solve the above problems, the present application provides a solution. SUMMARY

[0004] In order to overcome the above-mentioned defects of the prior art, the embodiments of the present application provide a remote communication module master-slave state monitoring and switching system to solve the problems raised in the background art.

[0005] To achieve the above-mentioned purpose, the present application provides the following technical solutions:

[0006] In one preferred embodiment, it comprises: a communication module state acquisition and reporting module, an upgrade determination and scheduling control module, a master-slave system state switching and flashing module, a radio frequency parameter backup and restoration module, and an upgrade result return and feedback module, the modules are connected by signals;

[0007] The communication module state acquisition and reporting module is used to acquire the current running state of the remote communication module, and to make preparations for remote upgrade and master-slave switching;

[0008] The upgrade judgment and scheduling control module judges whether the remote communication module needs to be upgraded and formulates an upgrade path;

[0009] The master-slave system state switching and flashing module is used for executing OTA flashing of a standby system partition under the premise that the module has a dual-firmware system structure, identifying a current running system through a start flag, downloading and writing firmware to a non-current partition, completing boot switching configuration, and monitoring a flashing health degree index during the flashing process. When entering a high-risk state, the flashing is interrupted, and a flashing snapshot and a boot state are reserved. In combination with a flashing exception flag, a flashing interruption snapshot validity, and a bootflag switching blocking lock state, it is determined whether to deploy a minimum system for flashing recovery. After deployment, an incremental repair of a damaged segment or a full-segment rewriting process is executed according to the stability of the main system.

[0010] The radio frequency parameter backup and restoration module is used for avoiding communication function failure caused by modem driver and RF parameter incompatibility under a cross-baseline condition.

[0011] The upgrade result return and feedback module is used for reporting an upgrade result to a remote platform.

[0012] In a preferred embodiment, in the communication module state acquisition and reporting module, the module is connected to a remote network environment, a communication link with an ACS network management platform is established, a local configuration file of the module is acquired, and a module upgrade requirement is determined.

[0013] In a preferred embodiment, in the upgrade judgment and scheduling control module, the ACS network management platform issues a scheduling task OTA package to the module. The module checks the OTA package, confirms the legality of the upgrade requirement and whether it constitutes a cross-baseline operation, and then formulates a flashing path.

[0014] In a preferred embodiment, in the master-slave system state switching and flashing module, the method for positioning a system partition currently running by the module is as follows: a start flag bit of a boot partition is read and a partition mapping relationship is compared to ensure that the flashing object is a non-current running system partition. After the firmware is written, a read-back verification is performed to confirm the writing integrity.

[0015] In a preferred embodiment, in the master-slave system state switching and flashing module, the calculation of the OTA flashing health degree is based on a writing success rate, a flashing progress, a verification result, and a flash writing time delay key index to build a weighted evaluation model to judge whether the current flashing state is in a risk stage.

[0016] In a preferred embodiment, in the master-slave system state switching and flashing module, when it is determined that it is in a risk stage and the minimum system needs to be deployed, the minimum system reads a flashing interruption snapshot to extract a breakpoint and a damaged position, and selects an incremental repair of a bad block or a full-segment rewriting mode of remote differential data to complete flashing recovery according to the running stability of the main system.

[0017] In a preferred embodiment, the radio frequency parameter backup and restoration module extracts key radio frequency configuration data, then detects the backup flag bit to determine the system backup state and trigger parameter recovery.

[0018] In a preferred embodiment, the upgrade result feedback module restarts the dial-up service and network management service client, compares the version identification fields of the pre-upgrade version and the target board, reports the current system and version number, confirms whether the upgrade is successful, and automatically judges and records the upgrade result.

[0019] The technical effects and advantages of the remote communication module master-slave state monitoring and switching system are as follows:

[0020] The present application introduces a minimum system intervention mechanism that can run independently in the master-slave system architecture of the remote communication module, enabling the risk of flashing failure to be actively perceived and timely repaired at the key stage, thereby breaking the dependence of the previous "passive rollback" strategy on the integrity of the master partition. In addition, by introducing a flashing health degree evaluation matrix and a dynamic risk grading strategy, the system can dynamically switch to a degraded flashing, backup recovery, or minimum system reconstruction path according to the actual risk level, achieving a multi-path stable transition and ensuring the stability of the flashing process. The radio frequency parameter protection module automatically completes QCN backup and restoration before and after the master-slave switching, effectively avoiding the problem of radio frequency configuration failure caused by partition switching and enhancing the consistency of the network side. The system modules are logically coupled but deployed decoupled, with high portability and engineering reuse value. The overall solution is suitable for resource-constrained terminal communication modules and can achieve high-availability remote upgrading without relying on external support, significantly improving system stability, security, and operation efficiency. BRIEF DESCRIPTION OF DRAWINGS

[0021] Figure 1 The module schematic diagram of the remote communication module master-slave state monitoring and switching system.

[0022] Figure 2 The timing diagram of the remote communication module master-slave state monitoring and switching system. DETAILED DESCRIPTION

[0023] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative labor are within the scope of protection of the present application.

[0024] EMBODIMENT

[0025] The application discloses a remote communication module master-slave state monitoring and switching system, as shown in the figure, comprising a communication module state acquisition and reporting module, an upgrade judgment and dispatch control module, a master-slave system state switching and rewriting module, a radio frequency parameter backup and restoration module and an upgrade result return and feedback module, and signal connection between the modules. Figure 1

[0026] The communication module state acquisition and reporting module is mainly used for acquiring the current running state of the remote communication module, and making preparation for remote upgrade and master-slave switching.

[0027] Specifically, in the communication module state acquisition and reporting module, first, after the module is powered on, the initialization dialing service daemon (PPPDaemon) or QMIDialer is used to call the cellular communication stack in the communication module, to drive the SIM card to complete the network registration process. In the process, the communication module establishes a PPP or IP channel according to the preset APN parameter, and completes DNS resolution and IP address allocation through the built-in network stack module. After confirming the success of the public network address allocation, the link initialization with the remote ACS platform is immediately initiated, and HTTP or HTTPS is used as the transmission protocol channel to realize the effective opening of the management channel.

[0028] After the link is established, the module starts the state data preparation process, first reads the state data block in the local configuration storage area through system parameter management.

[0029] It should be noted that the data block is stored in an independent partition and contains the current firmware version, system flag bit, historical upgrade record and hardware baseline number.

[0030] Then, the system confirms whether the current running system is a master system or a slave system according to the master-slave system bit field in the state flag, and analyzes the corresponding relationship between the current execution version and the preset baseline in combination with the version identification field, so as to determine whether the module has cross-version or cross-baseline upgrade demand.

[0031] After completing the local state analysis, the module calls the built-in network management communication client TR-069CPE, encapsulates the analyzed running state into a TR-069 protocol message in the form of structured parameters. At the same time, the client follows the TR-069SessionInitiation process, initiates the Inform message and attaches the module state parameter list, supports the authentication handshake and Session keeping mechanism, and ensures that the state reporting is carried out in a safe and reliable channel. After receiving the state message, the remote ACS platform can judge the upgrade strategy based on the current system version, running partition and baseline information, and provide data support for subsequent upgrade scheduling, master-slave switching and risk control decision.

[0032] ​The upgrade judgment and scheduling control module judges whether the remote communication module needs to be upgraded and formulates an upgrade path.

[0033] Specifically, in the upgrade judgment and scheduling control module, first, the ACS remote management platform matches the built-in upgrade strategy table based on the state parameters reported by the module, and schedules the upgrade task and issues the OTA resource path through the TR-069 protocol.

[0034] The scheduling process depends on the Download instruction interface in the TR-069 standard, the platform binds the task to the unique identifier of the module, and pushes the URL of the target OTA package and the task ID, realizing the initial distribution of the task level and the resource path on the network side. After the module receives the scheduling task, it starts the built-in network management client, downloads the OTA firmware package header according to the specified URL through the HTTP / HTTPS protocol, and reads the MagicNumber, firmware version number, baseline identifier and check value in the header field through the built-in check module. Use MD5 check algorithm to compare the integrity field of the package header to ensure that the OTA package structure is not damaged, and use the built-in format check function to match and verify the version number format, thereby realizing the preliminary confirmation of the legality of the upgrade package.

[0035] After the verification, the module continues to parse the baseline identifier of the current system from the local running system configuration area, and accurately matches the target baseline identifier field in the OTA package header. The comparison is completed through a double-field parsing matching engine, and the rule is based on the consistency of the firmware baseline to judge whether this upgrade constitutes a cross-baseline operation - if the current baseline is inconsistent with the target baseline, it is marked as "cross-baseline upgrade";

[0036] After the judgment is completed, the module formulates the flashing path according to whether it is cross-baseline, the current running system state, the system health state and the idle Flash space condition, by the local upgrade strategy judgment module. Among them, the path formulation rule adopts a multi-condition matching matrix, and combines the resource distribution priority issued by the platform, outputs the flashing mode selection result through the internal strategy matching logic, including whether to enable differential flashing, whether to force flashing the standby system, whether to backup the radio frequency parameter area, whether to set the Bootflag delay update and other control parameters, thereby forming an upgrade execution plan tailored for the current module state, and encapsulating the plan into an upgrade control parameter structure body.

[0037] The master-slave system state switching and flashing module is mainly used to upgrade and flash the standby system while ensuring the safety of the running system under the premise that the module has dual firmware systems.

[0038] Specifically, in the master-slave system state switching and flashing module, first, the starting flag bit preset in the boot partition is read to locate the system partition currently running by the module, wherein the locating process depends on the system index identification field in the boot area, which is read by the bootloader at the initial stage of module startup to determine the startup path. Further, by comparing the starting flag bit and the system partition mapping relationship, the system accurately identifies the system currently in the running state before upgrading, thereby ensuring that the upcoming flashing operation will not overwrite the current execution environment and avoiding system interruption.

[0039] After positioning, the module starts the upgrade task preprocessing, and according to the upgrade control parameter structure, the OTA download interface is called to pull the target firmware file to the module cache area. Then, the system control flow hands over the downloaded OTA package to the flashing control and starts the write operation on the partition where the standby system is located, i.e., the non-current running system. The flashing process uses the Flash write control interface to write the segmented firmware data in order after erasing the page-level block, and performs the CRC32 check function after writing each segment to ensure the consistency of the written data and the target segmented data, thereby improving the flashing reliability.

[0040] Further, after the firmware is written, the system calls the boot area update program to modify the starting pointer in the bootflag flag field to the target system partition number. This operation is completed by directly modifying the starting bit in the boot parameter table, and after the update is completed, the boot verification field is written to trigger the bootloader to take effect. The flag update of the boot area needs to be completed when the system is in the running state, and the read-back verification is performed after the writing is successful to prevent the flag update from failing due to voltage fluctuations or abnormal power failure, thereby avoiding the misboot into the system that has not been flashed. After completing the modification of the boot flag, the system marks the upgrade task as "switching preparation completed" state and enters the restart phase. The module calls the soft restart mechanism through the safe restart interface to reload the bootloader in this phase. In the bootloader startup process, the latest target system identification is read according to the boot flag, the system kernel and the starting file system are loaded from the specified partition, and finally the startup activation of the new system is realized.

[0041] It should be noted that considering that in small-capacity storage communication modules, the master-slave dual system partition structure will cause the firmware size to grow due to multiple drivers and baseline resource packages, resulting in partition space shortage and being unable to accommodate one copy of the complete main system and standby system; at the same time, the master-slave system can only share part of the resource area or can only write part of the OTA package content, and if the standby system is incomplete after the bootflag is changed, the module will become a brick and cannot guarantee the integrity of the standby system, and the traditional master-slave dual system flashing method is too risky to be used in such small-capacity modules, therefore, for such a case, in the embodiment, the master-slave system state switching and flashing module is modified as follows:Figure 2 As shown, when OTA is written to a non-current running system partition, key indicator data such as the success rate of OTA writing, the writing progress, the checksum, and the flash writing delay are collected in real time through embedded writing monitoring, and a weighted evaluation model is constructed to determine the writing state of OTA at this time, calculate the OTA writing health at this time, and then set a health threshold. When the OTA writing health at this time is greater than or equal to the health threshold, it indicates that the OTA writing risk is significant at this time, and the traditional master-slave dual-system writing method is completely unusable, which belongs to the risk stage. At this time, the current writing task needs to be interrupted immediately through the writing process controller, and the writing exception flag bit is written in the reserved Flash area without erasing the existing system partition, while the current writing snapshot, firmware segment index, and flash state log are retained. After the exception record is completed, the monitoring bootflag switching block state is avoided to avoid booting into the incomplete standby system. Then, the system reads the current bootflag switching control state through the boot area state recognition logic, and reads the writing exception flag WFF and the writing interruption snapshot validity marker SNP jointly.

[0042] Then, a state joint determination matrix is used to dynamically make the optimal deployment of the minimum system that does not participate in the space allocation of the master-slave system partition and cannot be erased or covered by the OTA process based on the triple-dimensional logical intersection of the writing exception flag bit WFF, the writing interruption snapshot information SNP, and the bootflag switching block lock state BLS. Among them, the writing exception flag bit determines whether the deployment of the minimum system must intervene in the writing operation; the writing interruption snapshot information determines whether the deployment of the minimum system can intervene in the writing operation; and the bootflag switching block lock state determines whether the intervention of the deployed minimum system in the writing operation is reliable. The specific logic is as follows:

[0043] WFF=1, SNP=1, BLS=1, which indicates that the writing is abnormal, the snapshot is complete, the bootflag has not been switched, and the system is currently running normally. At this time, all three aspects are met, the minimum system can read failed data, execute repair logic, and complete boot switching when it intervenes, and the immediate deployment of the minimum system is the best choice.

[0044] WFF=1, SNP=1, BLS=0, which indicates that the writing is abnormal, the snapshot is complete, but the standby system has been entered, indicating that the bootflag has not been locked and the system boot has entered a damaged environment; even if the snapshot is complete, the system running environment is not trustworthy and cannot mount the minimum system resource area; the deployment of the minimum system will fail, and even the system cannot normally load the driver. At this time, the deployment of the minimum system is strictly prohibited, and the risk is extremely high.

[0045] WFF=1, SNP=0, BLS=1, indicating that the flashing is abnormal, the snapshot is lost, and the bootflag is not jumped, indicating that the system is currently stable, but there is no snapshot, and the minimum system cannot accurately obtain the damage point, the flashing recovery precision is low, and it is necessary to pull the differential data from the remote again, perform blind repair, the risk is increased, and it is necessary to re-identify the damaged segment or skip the damaged area; at this time, deployment can be deployed, but it is not the best time;

[0046] WFF=0, indicating that the flashing is not abnormal, and the minimum system deployment will consume system resources, interrupt the normal process, and introduce uncertainty, so deployment is not allowed at this time, and the original OTA process should be continued.

[0047] Further, a comprehensive score D is defined for quantifying the quality of the current deployment opportunity, and a weighted scoring formula is used to weight the three state values, and a deployment decision is made based on the scoring result.

[0048] Next, after the minimum system is deployed, first, the flashing breakpoint and data damage segment position are extracted by reading the flashing interrupt snapshot information reserved in the shared Flash area, and the current main system running state is monitored by the built-in heartbeat detection logic to determine whether it is stable, if the main system is still stable, the minimum system converts the OTA flashing process into a damaged segment incremental repair process by scheduling the recovery task logic controller, uses a bad block jump writing strategy to skip the damaged area, and performs segment-level writing and boot area reconstruction; if the main system is in an unstable or failed state, the minimum system automatically takes over the network management communication function, establishes a low-resource connection with the remote ACS using the embedded lightweight TR-069 communication client, re-requests this OTA differential resource and executes the full segment rewriting and driver table remapping process, thereby completing the full-link damage recovery.

[0049] After the flashing repair process is completed, the minimum system confirms the repair success by quickly comparing the hash check value of the repair area firmware with the target firmware baseline version field configured by the remote platform, and automatically modifies the bootflag to the target partition and executes system restart, finally realizes the safe switching of the system from master to slave through the controlled boot process, and ensures that even in the case of high-risk failure during flashing, the system can also realize self-recovery, uninterrupted and online running state.

[0050] The radio frequency parameter backup and restoration module is mainly used to avoid communication function failure caused by modem driver and RF parameter incompatibility in cross-baseline situations;

[0051] Specifically, in the radio frequency parameter backup and restoration module, after the upgrade judgment module confirms that this remote upgrade is a cross-baseline upgrade scenario, the system automatically calls the modem parameter backup interface, extracts key radio frequency configuration data from the EFS partition of the current running system through the QCN read-write instruction issued by the Qualcomm platform, and writes the complete Modem parameters including frequency band configuration, power calibration, antenna mapping, etc. to the independent reserved partition that does not participate in the OTA flashing process, and sets the QCN backup completion flag to the active state to ensure that it can be reliably identified and restored in the subsequent system switching.

[0052] In the first start process of the new system after upgrading, the initialization module in the start process detects the QCN backup flag, and if it is identified as having completed backup, the parameter recovery process is triggered immediately, the original QCN file stored in the reserved area is automatically written back to the modem parameter path of the current system, and the parameter taking effect process is completed through the soft restart mechanism of the Modem subsystem, that is, the three stages of power down→ recovery writing→ power up fast Modem reinitialization. It is ensured that the Modem can use the radio frequency configuration parameters of the last system in the new system environment, thereby avoiding problems such as radio frequency driver failure, network registration exception or communication link interruption caused by baseline difference, and ensuring the radio frequency compatibility and functional continuity of the communication module in the cross-baseline scenario.

[0053] The upgrade result feedback module is mainly used to report the upgrade result to the remote platform, which is convenient for centralized control, log management and subsequent operation and maintenance.

[0054] Specifically, in the upgrade result feedback module, after the module completes firmware flashing and successfully starts, the system automatically restarts the dial-up service and TR-069 network management service client during initialization to ensure that the module reconnects to the public network and restores the communication channel with the remote ACS platform at the first time after starting. Then the TR-069 client automatically constructs and sends an Inform message containing the current system software version number, build number and baseline identification, and the platform receives it and compares it with the target version information recorded in the original task.

[0055] At the same time, the comparison process does not depend on manual intervention, and the platform automatically identifies the field consistency of the current reported version and the target version, and confirms whether the current upgrade has reached the expected result in combination with the module state. If all fields are consistent and the module is online, the system determines that the upgrade is successful and writes the status to the platform side upgrade log, otherwise if the fields are inconsistent, the module is offline or the message is abnormal, the system automatically triggers the upgrade failure record and marks the module as the priority object for subsequent manual operation and maintenance or automatic re-flashing task.

[0056] The above-described embodiments can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented by software, the above-described embodiments can be implemented in whole or in part in the form of a computer program product.

[0057] Those skilled in the art can realize that the modules and algorithm steps of the examples described in conjunction with the embodiments disclosed herein can be realized by electronic hardware or a combination of computer software and electronic hardware. Whether the functions are realized in hardware or software depends on the specific application and the constraints of the technical solution. Those skilled in the art can use different methods to realize the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0058] In addition, each functional module in each embodiment of the present application can be integrated into one processing module, or each module can exist physically alone, or two or more modules can be integrated into one module.

[0059] The above is merely specific embodiments of the present application, but the protection scope of the present application is not limited thereto, and any person skilled in the art can easily think of changes or replacements within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

[0060] Finally: the above is merely preferred embodiments of the present application, and is not intended to limit the present application, and any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the protection scope of the present application.

Claims

1. A remote communication module master-slave status monitoring and switching system, Its features include: a communication module status acquisition and reporting module, an upgrade judgment and scheduling control module, a master-slave system status switching and flashing module, an RF parameter backup and restoration module, and an upgrade result feedback module, with signal connections between the modules; The communication module status acquisition and reporting module is used to collect the current operating status of the remote communication module, in order to prepare for remote upgrades and master-slave switching. The upgrade determination and scheduling control module determines whether the remote communication module needs to be upgraded and formulates the upgrade path; The master-slave system state switching and flashing module is used to perform OTA flashing of the backup system partition when the module has a dual firmware system structure. It identifies the currently running system through the boot flag, downloads and writes the firmware to the non-current partition, and completes the boot switch configuration. During the flashing process, it monitors the flashing health indicators. When it enters a high-risk state, it interrupts the flashing and retains the flashing snapshot and boot state. It combines the flashing anomaly flag, the validity of the flashing interruption snapshot, and the bootflag switching blocking lock state to determine whether to deploy the minimum system for flashing recovery. After deployment, it performs incremental repair of damaged segments or full rewrite process based on the stability of the master system. In the master-slave system state switching and flashing module, the OTA flashing health is calculated based on a weighted evaluation model constructed from key indicators such as write success rate, flashing progress, verification results, and flash write latency to determine whether the current flashing status is in a risky stage. Furthermore, in the master-slave system state switching and flashing module, when it is determined that the system is in a risky phase and a minimum system needs to be deployed, the minimum system reads the flashing interruption snapshot to extract the breakpoint and the damaged location, and selects either incremental repair of bad blocks or remote differential data full rewriting method to complete the flashing recovery based on the stability of the master system. The RF parameter backup and restore module is used to prevent communication failure due to incompatibility of modem drivers and RF parameters in cross-baseline situations. The upgrade result feedback module is used to report the upgrade results to the remote platform.

2. The remote communication module master-slave status monitoring and switching system according to claim 1, characterized in that: In the communication module status acquisition and reporting module, the module is connected to a remote network environment, a communication link is established with the ACS network management platform, the module's local configuration file is obtained, and the module upgrade requirements are determined.

3. The remote communication module master-slave status monitoring and switching system according to claim 2, characterized in that: In the upgrade judgment and scheduling control module, the ACS network management platform sends the scheduling task OTA package to the module. The module verifies the OTA package to confirm the legality of the upgrade request and whether it constitutes a cross-baseline operation, and then determines the flashing path.

4. The remote communication module master-slave status monitoring and switching system according to claim 3, characterized in that; In the master-slave system state switching and flashing module, the method for locating the system partition currently running on the module is as follows: read the boot flag of the boot partition and compare the partition mapping relationship to ensure that the flashing object is not the currently running system partition, and perform read-back verification after the firmware is written to confirm the integrity of the write.

5. A remote communication module master-slave status monitoring and switching system according to claim 1, characterized in that: In the RF parameter backup and restore module, key RF configuration data is extracted, then the backup flag is detected to determine the system backup status and trigger parameter recovery.

6. A remote communication module master-slave status monitoring and switching system according to claim 5, characterized in that; In the upgrade result feedback module, the dial-up service and network management service client are restarted, the version identifier fields of the module and the previous version and the target board are compared, the current system and version number are reported, the success of the upgrade is confirmed, and the upgrade result is automatically judged and recorded.

Images