Configuration update sensing method and device, chip module and computer equipment

Abstract

The invention relates to the technical field of communication control, in particular to a configuration update sensing method and device, a chip module and computer equipment. The method is applied to a monitoring end and comprises the following steps: in response to a received notification message, reading a synchronous code of a target module from a shared memory; wherein the synchronization code is generated by the target module in response to the update of the configuration attribute and is written into the shared memory, and the notification message is generated by the target module when the target module determines that the updated configuration attribute is an emergency event and is sent to the monitoring end; when the monitoring end and any one of the function modules are powered on, the shared memory is powered on; acquiring a historical synchronous code of the target module, performing consistency comparison on the historical synchronous code and the synchronous code to obtain a sensing result, and updating the historical synchronous code by using the synchronous code; the sensing result represents whether the configuration attribute of the target module is updated or not. By adopting the scheme of the invention, the power consumption and the timeliness of configuration change perception can be balanced.

Description

Technical Field

[0001] This application relates to the technical field of communication control, and in particular to a configuration update sensing method, apparatus, chip module, and computer device. Background Technology

[0002] In mobile terminals, scenarios involving multi-module competitive resource coexistence scheduling, large-scale system cold and hot backup, and load balancing all require the ability to perceive configuration changes between different functional modules. For example, it is necessary to perceive and synchronize the configuration changes of the Bluetooth module and the Wi-Fi module to determine appropriate coexistence strategies and correct coexistence scheduling in order to effectively utilize time-division multiplexed hardware or air interface resources.

[0003] In related technologies, the monitoring terminal and functional modules are powered on and off independently. That is, when the configuration of a functional module changes, it sends a notification to the monitoring terminal. If the monitoring terminal is powered off, the notifications in the queue can only be processed sequentially when the monitoring terminal is powered on again. Therefore, the monitoring terminal may miss or delay some important configuration changes of the functional modules; while keeping the monitoring terminal and functional modules powered on synchronously will result in high power consumption.

[0004] Therefore, how to balance power consumption and the timeliness of configuration change perception is an urgent problem to be solved. Summary of the Invention

[0005] Therefore, it is necessary to provide a configuration update sensing method, device, chip module, and computer equipment that can balance power consumption and configuration change sensing to address the above-mentioned technical problems.

[0006] Firstly, this application provides a configuration update awareness method applied to a monitoring terminal, the method comprising:

[0007] In response to a received notification message, the synchronization code of the target module is read from the shared memory; wherein the synchronization code is generated and written to the shared memory by the target module in response to an update of the configuration attribute, and the notification message is generated and sent to the monitoring terminal by the target module when it determines that the updated configuration attribute is an emergency event; the shared memory is powered on when the monitoring terminal and any of the functional modules are powered on.

[0008] Obtain the historical synchronization code of the target module, compare the consistency of the historical synchronization code with the current synchronization code to obtain the perception result, and update the historical synchronization code using the current synchronization code; the perception result indicates whether the target module has undergone configuration attribute updates.

[0009] In one embodiment, the step of reading the synchronization code of the target module from shared memory in response to a received notification message includes:

[0010] When the monitoring terminal is powered off, it is woken up and powered on in response to the received notification message, and after being woken up and powered on, it reads the synchronization code of the target module from the shared memory;

[0011] When the monitoring terminal is powered on, it reads the synchronization code of the target module from the shared memory in response to the received notification message.

[0012] In one embodiment, the notification message includes an identity identifier, and the step of reading the synchronization code of the target module from shared memory includes:

[0013] Based on the identity identifier in the notification message, the target storage address corresponding to the target module in the shared memory is determined;

[0014] Access the target storage address and read the synchronization code of the target module.

[0015] In one embodiment, the synchronization code includes a configuration identifier and a checksum, and the bit width of the synchronization code is consistent with the bit width of the shared memory; the step of comparing the historical synchronization code with the current synchronization code to obtain a perception result includes:

[0016] The historical configuration identifier in the historical synchronization code is compared with the configuration identifier in the synchronization code to obtain the comparison result;

[0017] If the comparison results are inconsistent, the read check code is used as a check identifier, and the target check algorithm matching the target module is called to check the configuration identifier and the check identifier to obtain the check result;

[0018] If the verification result is valid, the perception result is determined to be an update of the configuration attributes of the target module.

[0019] Secondly, this application also provides a configuration update awareness method, applied to a functional module, the method comprising:

[0020] In response to an update of configuration attributes, a synchronization code is generated and written to shared memory; wherein, the shared memory is powered on when the monitoring terminal and any of the aforementioned functional modules are powered on.

[0021] When it is determined that the updated configuration attribute is an emergency event, a notification message is generated and sent to the monitoring terminal; the notification message is used to instruct the monitoring terminal to determine whether the configuration attribute in the functional module has been updated based on the synchronization code read from the shared memory.

[0022] In one embodiment, the synchronization code includes a configuration identifier and a checksum, and the generation of the synchronization code includes:

[0023] The configuration identifier is generated based on the update cycle of the configuration attribute;

[0024] Invoke the target encryption algorithm that matches the functional module, and process the configuration identifier based on the target encryption algorithm to obtain the verification code;

[0025] The synchronization code is generated based on the checksum and the configuration identifier; wherein the bit width of the synchronization code is the same as the bit width of the shared memory.

[0026] Thirdly, this application provides a configuration update sensing device, the device comprising a reading module and a sensing module, wherein:

[0027] The reading module is used to read the synchronization code of the target module from the shared memory in response to a received notification message; wherein the synchronization code is generated and written to the shared memory by the target module in response to an update of the configuration attribute, and the notification message is generated and sent to the monitoring terminal by the target module when it determines that the updated configuration attribute is an emergency event; the shared memory is powered on when the monitoring terminal and any of the functional modules are powered on.

[0028] The perception module is used to obtain the historical synchronization code of the target module, compare the historical synchronization code with the current synchronization code to obtain a perception result, and update the historical synchronization code using the current synchronization code; the perception result indicates whether the target module has undergone configuration attribute updates.

[0029] Fourthly, this application also provides a configuration update sensing device, the device comprising a synchronization code processing module and a message processing module, wherein:

[0030] The synchronization code processing module is used to generate a synchronization code in response to the update of the configuration attributes and write the synchronization code into the shared memory; wherein, the shared memory is powered on when the monitoring terminal and any of the functional modules are powered on.

[0031] The message processing module is used to generate a notification message and send the notification message to the monitoring terminal when it is determined that the updated configuration attribute is an emergency event; the notification message is used to instruct the monitoring terminal to determine whether the configuration attribute in the functional module has been updated based on the synchronization code read from the shared memory.

[0032] Fifthly, this application also provides a chip module, including multiple functional modules, a power module, a monitoring terminal, and shared memory, wherein:

[0033] The power module is used to supply power to the functional module, the monitoring terminal, and the shared memory module;

[0034] The functional module, in response to the update of the configuration attribute, generates a synchronization code and writes the synchronization code into the shared memory; wherein, the shared memory is powered on when the monitoring terminal and any one of the functional modules are powered on; and when it is determined that the updated configuration attribute is an emergency event, a notification message is generated.

[0035] The monitoring terminal, in response to the received notification message, reads the synchronization code of the target module from the shared memory; obtains the historical synchronization code of the target module, compares the historical synchronization code with the current synchronization code to obtain a perception result, and updates the historical synchronization code using the current synchronization code; the perception result indicates whether the target module has undergone configuration attribute updates.

[0036] In a sixth aspect, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the steps of the configuration update sensing method as described in either the first aspect or the second aspect above.

[0037] The aforementioned configuration update sensing method, device, chip module, and computer equipment enable the functional module to determine whether the target module's configuration update is an urgent event, sending notification messages only to wake up the monitoring terminal for urgent events. The shared memory is powered on synchronously with the functional module or the monitoring terminal, ensuring that the functional module can promptly write the generated synchronization code to the shared memory during configuration updates, and that the monitoring terminal can immediately read the target module's synchronization code from the shared memory upon being woken up. The monitoring terminal further compares the read synchronization code with pre-stored historical synchronization codes; if the comparison result indicates inconsistency, it can be determined that the target module's configuration attributes have been updated. The notification message sent by the target module to the monitoring terminal wakes up the monitoring terminal, thus avoiding any omissions or delays in the monitoring terminal's sensing of the functional module's configuration update caused by the monitoring terminal going into sleep mode during a target module configuration update.

[0038] Shared memory can store the synchronization code generated by the target module, avoiding the situation where the monitoring terminal cannot receive data when it is in sleep mode. Furthermore, since shared memory can be an API interface for registers or cloud storage, its power consumption is relatively low. Therefore, the power consumption when shared memory coexists with functional modules or the monitoring terminal is lower than that when functional modules coexist with the monitoring terminal. This greatly reduces the power consumption required for the monitoring terminal to perceive the configuration updates of emergency events in various functional modules. Attached Figure Description

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

[0040] Figure 1 This is a schematic diagram of the chip module structure in one embodiment;

[0041] Figure 2 This is a flowchart illustrating the configuration update awareness method executed by the monitoring terminal in one embodiment.

[0042] Figure 3 This is a schematic diagram of the process of reading the synchronization code at the monitoring end in one embodiment;

[0043] Figure 4 This is a schematic diagram of the process for determining the perceived result in one embodiment;

[0044] Figure 5 This is a flowchart illustrating the configuration update awareness method executed by a functional module in another embodiment;

[0045] Figure 6 This is a flowchart illustrating the process of generating a synchronization code in one embodiment;

[0046] Figure 7 This is a schematic diagram illustrating the interaction between the functional modules, the monitoring terminal, and the shared memory in another embodiment.

[0047] Figure 8 This is a schematic diagram of the synchronization code structure in one embodiment;

[0048] Figure 9 A structural block diagram of a configuration update sensing device in one embodiment;

[0049] Figure 10 A structural block diagram of the configuration update sensing device in another embodiment;

[0050] Figure 11 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0051] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0052] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0053] The configuration update awareness method provided in this application embodiment can be applied to, for example, Figure 1 The chip module shown includes at least one functional module (Worker), one monitoring terminal (Monitor), and at least one shared memory (Share mem). The functional module (Worker) and the monitoring terminal (Monitor) can communicate directly, and both the functional module (Worker) and the monitoring terminal (Monitor) can communicate with the shared memory (Share mem). However, the functional module (Worker) only has write permissions to the shared memory (Share mem), and the monitoring terminal (Monitor) only has read permissions to the shared memory (Share mem).

[0054] Multiple functional modules can be associated with a shared memory configuration. That is, through a monitoring terminal and a shared memory, the configuration updates of multiple functional modules can be detected.

[0055] Functional modules, including but not limited to BT (Bluetooth) sys and Wi-Fi sys; shared memory, which can be storage, such as hardware registers, or cloud storage service API (Application Programming Interface).

[0056] In one exemplary embodiment, such as Figure 2 As shown, a configuration update awareness method is provided, which is applied to... Figure 1 The monitoring terminal in the middle, or applied to Figure 1 Taking a chip module with data processing capabilities as an example, the explanation includes the following steps M10 and M20, wherein:

[0057] Step M10: In response to the received notification message, read the synchronization code of the target module from the shared memory.

[0058] In the embodiments of this application, the synchronization code is generated and written to shared memory by the target module in response to the update of the configuration attributes, and the notification message is generated and sent to the monitoring end by the target module when it determines that the updated configuration attributes are an emergency event.

[0059] Specifically, the target module is configured to generate a synchronization code when configuration attributes change and are updated. This synchronization code can be generated based on the updated configuration attributes or based on the update cycle of the configuration attributes. The target module updates configuration attributes in response to business messages generated by the business system. It can pre-associate urgent or regular tags with each business message, or pre-associate urgent or regular tags with each configuration attribute. The target module determines whether the configuration update is an urgent event based on the tags of the business message or the updated configuration attributes. Updates corresponding to urgent tags are urgent events, and updates corresponding to regular tags are regular events.

[0060] The target module is further configured to generate a notification message and send it to the monitoring terminal when its configuration attributes are updated and the updated attributes indicate an emergency event. When the monitoring terminal is powered down, it is woken up in response to the received notification message and processes the notification message to read the synchronization code written by the target module from shared memory. When the monitoring terminal is powered on, it directly processes the received notification message and reads the synchronization code of the target module from shared memory in response to the received notification message.

[0061] Furthermore, the shared memory is configured to power on synchronously with the monitoring terminal and with any functional module. This ensures that any functional module in the power-on state can write the generated synchronization code to the shared memory during configuration updates, and that the monitoring terminal can immediately read the corresponding functional module's synchronization code from the shared memory when it is woken up and powered on.

[0062] Step M20: Obtain the historical synchronization code of the target module, compare the consistency of the historical synchronization code with the synchronization code to obtain the perception result, and update the historical synchronization code using the synchronization code; the perception result indicates whether the target module has undergone configuration attribute updates.

[0063] In this embodiment, after the monitoring terminal reads the synchronization code of any functional module from the shared memory, it stores the read synchronization code as the historical synchronization code of that functional module. This historical synchronization code is updated only after the next read of the new synchronization code written to the shared memory by the functional module. Since the synchronization code generated by each functional module is based on changes in its configuration attributes, meaning that any change in configuration attributes will result in a corresponding change in the generated synchronization code, the monitoring terminal, after reading the synchronization code of the target module, obtains the previously generated synchronization code of the target module (i.e., the historical synchronization code). Then, it compares the currently read synchronization code of the target module with its historical synchronization code. Based on the comparison result, the monitoring terminal can then determine whether the configuration attributes of the target module have been updated.

[0064] In the above configuration update detection method, the functional module can determine whether the configuration update of the target module is an urgent event, and only sends a notification message to wake up the monitoring terminal for urgent events. The shared memory is powered on synchronously with the functional module or the monitoring terminal, ensuring that the functional module can write the generated synchronization code to the shared memory in a timely manner when updating the configuration, and that the monitoring terminal can read the target module's synchronization code from the shared memory immediately when it is woken up. The monitoring terminal further compares the read synchronization code with the pre-stored historical synchronization code. If the comparison result shows an inconsistency, it can be determined that the detection result is that the configuration attributes of the target module have been updated. The notification message sent by the target module to the monitoring terminal wakes up the monitoring terminal, thereby avoiding the omission or delay in the monitoring terminal's detection of the functional module's configuration update caused by the monitoring terminal going to sleep during the target module's configuration update.

[0065] Shared memory can store the synchronization code generated by the target module, avoiding the situation where the monitoring terminal cannot receive data when it is in sleep mode. Furthermore, since shared memory can be an API interface for registers or cloud storage, its power consumption is relatively low. Therefore, the power consumption when shared memory coexists with functional modules or the monitoring terminal is lower than that when functional modules coexist with the monitoring terminal. This greatly reduces the power consumption required for the monitoring terminal to perceive the configuration updates of emergency events in various functional modules.

[0066] In one embodiment, such as Figure 3 As shown, in step M10, the monitoring terminal reads the synchronization code of the target module from the shared memory, which may specifically include steps M11 and M12, wherein:

[0067] Step M11: Determine the target storage address of the target module in the shared memory based on the identity identifier in the notification message;

[0068] Step M12: Access the target storage address and read the synchronization code of the target module.

[0069] Specifically, each functional module is associated with a unique identifier to represent its identity; and the shared memory pre-sets the storage address corresponding to each functional module; the synchronization code generated by any functional module is written to its corresponding storage address in the shared memory.

[0070] Each functional module is configured to generate a notification message based on its identity identifier. When the monitoring terminal receives the notification message, it parses the message to obtain the identity identifier of the target module and determines the corresponding storage address of the target module in shared memory as the target storage address. Then, the monitoring terminal accesses the target storage address in shared memory to read the synchronization code written by the target module.

[0071] In one embodiment, the shared memory is configured such that, for each functional module, the synchronization code written is deleted as soon as it is read by the monitoring terminal; or, for each functional module, when the functional module writes a synchronization code to the corresponding storage address in the shared memory, it replaces the previously written synchronization code stored at that storage address. Thus, when the monitoring terminal accesses the target storage address, it can only read the synchronization code generated in real-time by the target storage module, avoiding erroneous readings.

[0072] In another embodiment, for each functional module, the shared memory module stores the synchronization codes written by that functional module to the corresponding storage address, and each synchronization code is associated with a write timestamp / generation timestamp. When the monitoring terminal accesses the target storage address, it reads the synchronization code with the latest timestamp according to the order of the timestamps.

[0073] The above content describes how the monitoring terminal responds to notification messages sent by the target module and how it reads the synchronization code from shared memory; the following content further explains how the monitoring terminal determines the perception result based on the read synchronization code.

[0074] Communication between functional modules and shared memory, as well as communication between shared memory and modules, is susceptible to data loss or errors. To improve the efficiency of storing and retrieving synchronization codes, these codes are typically not very complex. This means that if an error occurs in the synchronization code during transmission, it can lead to inaccurate perception results from the monitoring end. To avoid this, this application provides a novel synchronization code structure. The synchronization code in this embodiment includes a configuration identifier and a checksum. The configuration identifier is generated in response to updates to the configuration attributes of the functional module, while the checksum is obtained by processing the configuration identifier using an encryption algorithm. Concatenating the configuration identifier and the checksum yields the synchronization code.

[0075] like Figure 4As shown, in step M20, the historical synchronization code is compared with the synchronization code to obtain the sensing result. Specifically, this may include steps M21-M23, wherein:

[0076] Step M21: Compare the historical configuration identifier in the historical synchronization code with the configuration identifier in the synchronization code to obtain the comparison result.

[0077] Step M22: If the comparison results are inconsistent, the read check code is used as the check identifier, and the target check algorithm that matches the target module is called to check the configuration identifier and the check identifier to obtain the check result.

[0078] Specifically, during the monitoring period, the update round of the configuration attributes for each functional module is initialized to 0. When the configuration attributes of each functional module are updated, a configuration identifier is generated based on the update round. Then, the functional module calls the target encryption algorithm corresponding to that module to encrypt the configuration identifier and obtain a verification code. Finally, the configuration identifier and the verification code are concatenated and written into shared memory as a synchronization code.

[0079] After reading the synchronization code from shared memory, the monitoring terminal compares the configuration identifier in the synchronization code with the historical configuration identifier in the historical synchronization code to obtain a comparison result. Specifically, it compares whether the configuration identifier and the historical configuration identifier are consistent; the comparison result indicates whether the configuration attributes of the target module have been updated. Further, if the comparison result is determined to be inconsistent, it is determined that the configuration attributes of the target module have been updated. Further, the monitoring terminal uses the checksum in the read synchronization code as a checksum identifier, calls the target checksum algorithm matching the target module, decrypts the checksum identifier using the target checksum algorithm, and verifies the decryption result against the configuration identifier. The checksum result indicates whether the comparison result is valid.

[0080] Step M23: If the verification result is valid, determine that the perception result indicates that the target module has updated its configuration attributes.

[0081] Specifically, if the verification result indicates that the decryption result is consistent with the configuration identifier, then the comparison result between the configuration identifier and the historical configuration identifier is determined to be valid, that is, the perception result indicates that the target module has undergone a configuration attribute update. If the verification result indicates that the decryption result is inconsistent with the configuration identifier, then the monitoring end rereads the synchronization code corresponding to the target module from the shared memory and re-executes step 20; if the verification result is still inconsistent, the monitoring end generates a regeneration instruction and sends it to the target module; the regeneration instruction is used to instruct the target module to regenerate the synchronization code and store it in the target storage address of the shared memory.

[0082] In one possible implementation, all functional modules can use the same encryption algorithm, in which case the monitoring terminal only needs to configure a verification algorithm corresponding to the encryption algorithm. In another possible implementation, each functional module can be configured with its own encryption algorithm, in which case the monitoring terminal needs to configure a verification algorithm corresponding to each encryption algorithm. When each functional module has its own encryption algorithm, the complexity of the encryption algorithm can be determined based on the communication stability (success rate) of the functional module; that is, the higher the communication stability, the lower the complexity of the encryption algorithm.

[0083] The above describes the implementation of the configuration change detection method for each functional module from the perspective of the monitoring end. The following example illustrates the implementation of the configuration change detection method for a functional module from the perspective of a single functional module.

[0084] In one exemplary embodiment, a configuration update awareness method is provided, which is applied to Figure 1 Functional modules (Workers) or applications Figure 1 This will be illustrated using a chip module with data processing capabilities as an example; such as Figure 5 As shown, the configuration update awareness method includes the following steps W10 and W20, wherein:

[0085] Step W10: In response to the update of configuration attributes, generate a synchronization code and write the synchronization code to the shared memory; wherein, the shared memory is powered on when the monitoring terminal or any of the functional modules is powered on.

[0086] In this embodiment of the application, the target module is configured to update configuration attributes in response to business messages generated by the business system; and the target module is also configured to generate a synchronization code when the configuration attributes change and are updated; wherein, the synchronization code may be generated based on the updated configuration attributes or based on the update cycle of the configuration attributes.

[0087] The target module is further configured to generate a notification message and send it to the monitoring terminal when its configuration attributes are updated and the updated attributes indicate an emergency event. When the monitoring terminal is powered down, it is woken up in response to the received notification message and processes the notification message to read the synchronization code written by the target module from shared memory. When the monitoring terminal is powered on, it directly processes the received notification message and reads the synchronization code of the target module from shared memory in response to the received notification message.

[0088] Furthermore, the shared memory is configured to power on synchronously with the monitoring terminal and with any functional module. This ensures that any functional module in the power-on state can write the generated synchronization code to the shared memory during configuration updates, and that the monitoring terminal can immediately read the corresponding functional module's synchronization code from the shared memory when it is woken up and powered on.

[0089] Step W20: When it is determined that the updated configuration attribute is an emergency event, a notification message is generated and sent to the monitoring terminal. The notification message is used to instruct the monitoring terminal to determine whether the configuration attribute in the functional module has been updated based on the synchronization code read from the shared memory.

[0090] In this embodiment of the application, emergency tags or regular tags can be pre-associated with each business message, or emergency tags or regular tags can be pre-associated with each configuration attribute; the target module determines whether the configuration update is an emergency event based on the tags of the business message or the updated configuration attribute; wherein, the update corresponding to the emergency tag is an emergency event, and the update corresponding to the regular tag is a regular event.

[0091] Each functional module is associated with a unique identifier to represent its identity; and the shared memory pre-sets the storage address corresponding to each functional module; the synchronization code generated by any functional module is written to its corresponding storage address in the shared memory.

[0092] Each functional module is configured to generate a notification message based on its identity identifier. When the monitoring terminal receives the notification message, it parses the message to obtain the identity identifier of the target module and determines the corresponding storage address of the target module in shared memory as the target storage address. Then, the monitoring terminal accesses the target storage address in shared memory to read the synchronization code written by the target module.

[0093] After reading the synchronization code of any functional module from shared memory, the monitoring terminal stores the read synchronization code as the historical synchronization code of that functional module. This historical synchronization code is updated the next time the functional module's new synchronization code is read from shared memory. Since the synchronization code generated by each functional module is based on changes in its configuration attributes, any change in configuration attributes will result in a corresponding change in the generated synchronization code. Therefore, after reading the synchronization code of the target module, the monitoring terminal obtains the previously generated synchronization code of the target module (i.e., the historical synchronization code) and compares the currently read synchronization code with its historical synchronization code. Based on the comparison result, the monitoring terminal can detect whether the target module's configuration attributes have been updated.

[0094] In the above configuration update detection method, the functional module can determine whether the configuration update of the target module is an urgent event, and only sends a notification message to wake up the monitoring terminal for urgent events. The shared memory is powered on synchronously with the functional module or the monitoring terminal, ensuring that the functional module can write the generated synchronization code to the shared memory in a timely manner when updating the configuration, and that the monitoring terminal can read the target module's synchronization code from the shared memory immediately when it is woken up. The monitoring terminal further compares the read synchronization code with the pre-stored historical synchronization code. If the comparison result shows an inconsistency, it can be determined that the detection result is that the configuration attributes of the target module have been updated. The notification message sent by the target module to the monitoring terminal wakes up the monitoring terminal, thereby avoiding the omission or delay in the monitoring terminal's detection of the functional module's configuration update caused by the monitoring terminal going to sleep during the target module's configuration update.

[0095] Shared memory can store synchronization codes generated by the target module, avoiding the situation where the monitoring terminal cannot receive data when it is in sleep mode. This is because the monitoring terminal can read the synchronization code from the shared memory after being woken up by the notification message sent by the functional module. Furthermore, since shared memory can be an API interface for registers or cloud storage, its power consumption is relatively low. Therefore, the power consumption when shared memory coexists with functional modules or the monitoring terminal is lower than the power consumption when functional modules coexist with the monitoring terminal. This greatly reduces the power consumption required for the monitoring terminal to perceive the configuration updates of emergency events in various functional modules.

[0096] The process of generating synchronization codes by the functional modules is further explained in detail below.

[0097] In one embodiment, the synchronization code includes a configuration identifier and a checksum; refer to Figure 6 The process of generating the synchronization code may specifically include steps W11-W13, wherein:

[0098] Step W11: Generate a configuration identifier based on the update cycle of the configuration attributes;

[0099] Step W12: Invoke the target encryption algorithm that matches the functional module, and process the configuration identifier based on the target encryption algorithm to obtain the verification code;

[0100] Step W13: Generate a synchronization code based on the checksum and configuration identifier; wherein the bit width of the synchronization code is consistent with the bit width of the shared memory.

[0101] Specifically, during the monitoring period, the update round of the configuration attributes for each functional module is initialized to 0. When the configuration attributes of each functional module are updated, a configuration identifier is generated based on the update round. Then, the functional module calls the target encryption algorithm corresponding to that module to encrypt the configuration identifier and obtain a verification code. Finally, the configuration identifier and the verification code are concatenated and written into shared memory as a synchronization code.

[0102] In one possible implementation, all functional modules can use the same encryption algorithm, in which case the monitoring terminal only needs to configure a verification algorithm corresponding to the encryption algorithm. In another possible implementation, each functional module can be configured with its own encryption algorithm, in which case the monitoring terminal needs to configure a verification algorithm corresponding to each encryption algorithm. When each functional module has its own encryption algorithm, the complexity of the encryption algorithm can be determined based on the communication stability (success rate) of the functional module; that is, the higher the communication stability, the lower the complexity of the encryption algorithm.

[0103] In one embodiment, when the configuration attributes of a functional module are updated, and the functional module determines that the configuration update is a regular event based on the business message / updated configuration attributes, the functional module also generates a synchronization code according to the above process and writes the synchronization code into the storage address corresponding to the functional module in the shared memory.

[0104] In one possible implementation, each functional module has two communication channels with the monitoring terminal, namely the first channel and the second channel.

[0105] When a functional module determines that a configuration update is an emergency event, it sends a generated notification message to the monitoring terminal through the first channel. The monitoring terminal then responds to the notification message received from the first channel by reading the synchronization code from the shared memory, or the monitoring terminal is woken up and powered on in response to the notification message received from the first channel, and then reads the synchronization code from the shared memory.

[0106] When the functional module determines that a configuration update is a regular event, it sends a generated notification message to the monitoring terminal via the second channel. Upon receiving the notification message from the second channel, if the monitoring terminal is powered on, it also responds by reading the synchronization code from shared memory. If the monitoring terminal is in a sleep state upon receiving the notification message from the second channel, it does not respond at all. Instead, it waits until it is woken up by a notification message from the first channel or powers on automatically before processing the notification messages cached in the second channel's message queue.

[0107] In another possible implementation, each functional module has only one communication channel with the monitoring terminal. When a functional module determines that a configuration update is an emergency event, it sends a generated first notification message to the monitoring terminal. The monitoring terminal then responds to the received first notification message by reading the synchronization code from shared memory, or by being woken up and powered on in response to the received first notification message, and then reading the synchronization code from shared memory.

[0108] When the functional module determines that the configuration update is a regular event, it sends a generated second notification message to the monitoring terminal. Upon receiving the second notification message, if the monitoring terminal is powered on, it also responds by reading the synchronization code from shared memory. If the monitoring terminal is in a sleep state upon receiving the second notification message, it does not respond at all, but waits until it is woken up by the first notification message or automatically powered on before processing the second notification message cached in the message queue.

[0109] The above embodiments illustrate the implementation of the configuration update awareness method from the perspective of functional modules. The following embodiments further elaborate on the specific implementation of the configuration update awareness method from the perspective of interaction between a monitoring terminal and a functional module.

[0110] In one exemplary embodiment, this application provides a configuration update awareness method applicable to chip modules. The chip module includes at least one functional module (Worker), one monitoring terminal (Monitor), and at least one shared memory (Share memory). The functional module (Worker) and the monitoring terminal (Monitor) can communicate directly, and both can communicate with the shared memory (Share memory). The functional module (Worker) only has write permissions to the shared memory (Share memory), and the monitoring terminal (Monitor) only has read permissions to the shared memory (Share memory). Multiple functional modules can be associated with a single shared memory configuration; that is, through one monitoring terminal and one shared memory, the awareness of configuration updates for multiple functional modules can be achieved.

[0111] The configuration update awareness method provided in this application has the following core innovations:

[0112] 1. By partitioning and abstracting into independent single PVs (i.e., single producer and single consumer), each functional module (Worker) only has write permission to the shared memory, while the monitoring terminal (Monitor) only has read permission to the shared memory; at the same time, the operation of the functional module is aligned with the operation address bus to achieve lock-free synchronization code read and write.

[0113] 2: The synchronization code adopts the method of "configuration identifier + synchronization code check code", which can both identify the configuration and support the self-identification (verification) of synchronization code anomalies.

[0114] 3: Share mem decouples the simultaneous power-on limitation of Monitor sys and Worker sys;

[0115] 4: Notification messages and shared memory read / write operations coexist. The decision on whether to wake up Monitor sys for notification messages is based on the urgency of the configured event.

[0116] like Figure 7 The diagram shown illustrates the interaction between the monitoring terminal, functional modules, and shared memory in the configuration update perception method.

[0117] ①: Add a shared memory (share mem) between the Worker sys and Monitor sys, which is independently powered on and off and accessible to both (e.g., a bus in different domains). The shared memory can be a memory (e.g., cloud storage) or a hardware register. In this scheme, the shared memory is called share mem and is used to store the Worker's configuration synchronization code. After the Worker configuration changes, the Worker generates a new synchronization code (sync_code) with a new bit width.

[0118] The sync_code consists of two parts: a "configuration identifier" and a "checksum". The number of bits in each part is determined by the algorithm.

[0119] The "configuration identifier" can be represented by a count mapping configuration or a hash mapping configuration, which are accumulated in a loop. For example, it can be counted based on the number of changes (updates), incrementing by 1 for each configuration change.

[0120] The "checksum" is used to verify the validity of the sync_code. Different algorithms, such as CRC, hash, and inverse code, can be selected based on the reliability of communication between the worker and the monitor.

[0121] Taking a 16-bit sync_code where the "checksum" is the complement of the "configuration identifier" (not limited to this method) as an example, the structure of the synchronization code is as follows: Figure 8 As shown.

[0122] ②: The Worker updates the sync_code to the shared memory without locking. It should be noted that the sync_code field in the shared memory must be defined at an address aligned to the bit width (such as the commonly used 32-bits or 64-bits). At the same time, the sync_code is consistent with the bit width. There is no "unaligned data transfer" situation when reading and writing. Therefore, no additional lock mutual exclusion protection is needed when reading and writing the sync_code in the shared memory.

[0123] ③: Based on the urgency or routine nature of the configuration update, the Worker sends a message with different capabilities or notifies the Monitor through a different capability channel. For configuration changes with high immediacy (urgent events), this message is needed to wake up the monitor sys for immediate processing. For changes with low immediacy (routine events), a message without the capability to wake up the monitor sys is sent.

[0124] ④: The Monitor reads the sync_code in the shared memory without locking, and the timing of the read can be divided into three cases:

[0125] The Monitor sys is powered on when a notification message arrives, and upon receiving the message, it immediately reads the sync_code from the shared memory.

[0126] The Monitor sys is normally powered down when the notification message arrives, but if the message or message channel has the sys wake-up capability, the Monitor sys will be woken up first, and then the sync_code in the shared mem will be read according to the received message.

[0127] When the notification message arrives, the monitor sys is in a power-off state, and the message or message channel does not have the ability to wake up the monitor. At this time, the monitor sys does not perform any processing. When the monitor sys is woken up and powered on again, it actively reads the sync_code in the shared memory.

[0128] ⑤: Verify the sync_code. Extract the checksum from the sync_code, and then use the agreed-upon checksum algorithm to verify its validity. Taking the 16-bit sync_code example from "Step 1" as an example, if the checksum and configuration identifier are inverses of each other, the sync_code is valid; otherwise, it is invalid. If the sync_code is valid, proceed directly to step 7 for configuration change judgment; otherwise, execute step 6.

[0129] ⑥: (Handling of Synchronization Code Reading Errors): The Monitor re-reads the synchronization code in the shared memory in a lock-free manner and verifies it. If the verification is successful, it proceeds to step 7; otherwise, it sends a message to the Worker, requesting the Worker to update the synchronization code in the shared memory, and then repeats steps 2 to 5.

[0130] ⑦: If the synchronization codes are the same, the perception result is determined to be that the configuration has not been updated; otherwise, it is determined that the configuration has been updated.

[0131] The beneficial effects of adopting the configuration update awareness method provided by this application at least include the following aspects:

[0132] Beneficial effect 1: Worker sys and Monitor sys are powered on and off independently, and the notification message does not depend on waking up the peer sys, with low power consumption.

[0133] As long as either Worker sys or Monitor sys is not powered off, share mem remains powered on. Therefore, it exists as a proxy module for configuration change information. So Worker can write to share mem at any time, and Monitor can read from share mem at any time. Therefore, independent power on and off can effectively reduce the device power consumption.

[0134] Beneficial effect 2: Lock-free reading and writing bring high performance.

[0135] Adopt a data marking synchronization code with the same bit width as share mem, and align the read and write addresses with the share mem bit width. So any read or write operation can be completed within one operation cycle. There is no data incompleteness caused by bus alignment, etc., and the read and write can be regarded as atomic operations.

[0136] Beneficial effect 3: Self-checking of the synchronization code, and Monitor can actively identify synchronization code anomalies and recover.

[0137] Taking the check code as the inverse code of the configuration hash_code (not limited to this method) as an example: synchronization code = (hash_code << N / 2) | (the inverse code of hash_code). So the result of the exclusive OR of the two numbers is always a number with all N bits inverted, otherwise it is a data error.

[0138] Beneficial effect 4: As long as Monitor is working, it can reliably sense the configuration changes of worker.

[0139] During the power-on period of Monitor, when it receives a message, it immediately obtains the synchronization code and confirms the configuration change. During the power-off period of Monitor, when it is powered on, it can also confirm the configuration changes of worker before working by obtaining the synchronization code.

[0140] Beneficial effect 5: Does not depend on a specific bus or memory structure.

[0141] Worker sys, Monitor sys, and share mem do not need to be on the same bus, and they can work as long as they can communicate with each other.

[0142] Among them, the limitations on the monitoring end, shared memory, and functional modules in the above embodiments can be applied to each other, and no more elaboration will be given here.

[0143] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0144] Based on the same inventive concept, this application also provides a configuration update sensing device for implementing the configuration update sensing method described above. This device can be applied to or integrated into a chip or chip module, for example. The solution provided by this device is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more configuration update sensing device embodiments provided below can be found in the limitations of the configuration update sensing method described above, and will not be repeated here.

[0145] In one exemplary embodiment, such as Figure 9 As shown, a configuration update sensing device 900 is provided, which includes a reading module 901 and a sensing module 902, wherein:

[0146] The reading module 901 is used to read the synchronization code of the target module from the shared memory in response to the received notification message; wherein, the synchronization code is generated and written to the shared memory by the target module in response to the update of the configuration attributes, and the notification message is generated and sent to the monitoring terminal by the target module when it determines that the updated configuration attributes are an emergency event; the shared memory is powered on when the monitoring terminal and any of the functional modules are powered on.

[0147] The perception module 902 is used to obtain the historical synchronization code of the target module, compare the historical synchronization code with the synchronization code to obtain the perception result, and update the historical synchronization code using the synchronization code; the perception result indicates whether the target module has undergone configuration attribute updates.

[0148] In one embodiment, the reading module 901 is specifically used for:

[0149] When the monitoring terminal is powered down, it is woken up and powered on in response to the received notification message, and after being woken up and powered on, it reads the synchronization code of the target module from the shared memory;

[0150] When the monitoring terminal is powered on, it reads the synchronization code of the target module from the shared memory in response to the received notification message.

[0151] In one embodiment, the reading module 901 is specifically used for:

[0152] Based on the identity identifier in the notification message, determine the target storage address of the target module in the shared memory;

[0153] Access the target storage address and read the synchronization code of the target module.

[0154] In one embodiment, the synchronization code includes a configuration identifier and a checksum, and the bit width of the synchronization code is consistent with the bit width of the shared memory; the sensing module is specifically used for:

[0155] The historical configuration identifier in the historical synchronization code is compared with the configuration identifier in the synchronization code to obtain the comparison result.

[0156] If the comparison results are inconsistent, the read check code is used as the check identifier, and the target check algorithm that matches the target module is called to check the configuration identifier and the check identifier to obtain the check result.

[0157] If the verification result is valid, the perception result indicates that the target module has updated its configuration attributes.

[0158] In one exemplary embodiment, such as Figure 10 As shown, a configuration update sensing device 100 is provided, which includes a synchronization code processing module 101 and a message processing module 102, wherein:

[0159] The synchronization code processing module 101 is used to generate a synchronization code in response to the update of the configuration attributes and write the synchronization code into the shared memory; wherein, the shared memory is powered on when the monitoring terminal or any of the functional modules is powered on.

[0160] The message processing module 102 is used to generate a notification message and send the notification message to the monitoring terminal when it is determined that the updated configuration attribute is an emergency event. The notification message is used to instruct the monitoring terminal to determine whether the configuration attribute in the functional module has been updated based on the synchronization code read from the shared memory.

[0161] In one embodiment, the synchronization code includes a configuration identifier and a check code, and the synchronization code processing module 101 is specifically used for:

[0162] Generate configuration identifiers based on the update cycle of configuration attributes;

[0163] Invoke the target encryption algorithm that matches the functional module, and process the configuration identifier based on the target encryption algorithm to obtain the verification code;

[0164] A synchronization code is generated based on the checksum and configuration identifier; the bit width of the synchronization code is the same as that of the shared memory.

[0165] Regarding the modules / units included in the various devices and products described in the above embodiments, they can be software modules / units, hardware modules / units, or a combination of both. For example, for various devices and products applied to or integrated into a chip, all of their modules / units can be implemented using hardware methods such as circuits, or at least some modules / units can be implemented using software programs that run on a processor integrated within the chip, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits; for various devices and products applied to or integrated into a chip module, all of their modules / units can be implemented using hardware methods such as circuits, and different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components of the chip module, or at least some modules / units can be implemented using hardware methods such as circuits. The components can be implemented using software programs that run on the processor integrated within the chip module. The remaining (if any) modules / units can be implemented using hardware methods such as circuits. For various devices and products applied to or integrated into the terminal, each of its components / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or in different components within the terminal. Alternatively, at least some modules / units can be implemented using software programs that run on the processor integrated within the terminal, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits.

[0166] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 11As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a configuration update perception method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0167] Those skilled in the art will understand that Figure 11 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0168] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps as described in the above embodiments of the configuration update awareness method applied to a monitoring terminal and / or applied to a functional module.

[0169] Based on the same inventive concept, this application also provides a chip module, such as... Figure 1 As shown, the chip module includes a communication module, a power module, a storage module, and a chip. Among them:

[0170] The power module is used to supply power to the functional modules, the monitoring terminal, and the shared memory module;

[0171] The functional module, in response to an update of configuration properties, generates a synchronization code and writes the synchronization code to shared memory; when it determines that the updated configuration property is an emergency event, it generates a notification message.

[0172] On the monitoring end, in response to the received notification message, the synchronization code of the target module is read from the shared memory; the historical synchronization code of the target module is obtained, the historical synchronization code is compared with the synchronization code to obtain the perception result, and the historical synchronization code is updated using the synchronization code; the perception result indicates whether the configuration attributes of the target module have been updated.

[0173] However, the shared memory, the monitoring terminal, and the functional modules are all powered by independent power domains; when the monitoring terminal or any of the functional modules is powered on, the shared memory is powered on as well.

[0174] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps described above in the embodiments of the configuration update perception method applied to a monitoring terminal and / or applied to a functional module.

[0175] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps described above in the embodiments of the configuration update awareness method applied to a monitoring terminal and / or applied to a functional module.

[0176] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0177] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0178] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0179] The above embodiments are merely illustrative of several implementation methods of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A configuration update awareness method, characterized by, Applied to the monitoring terminal, the method includes: In response to a received notification message, the synchronization code of the target module is read from the shared memory; wherein the synchronization code is generated and written to the shared memory by the target module in response to an update of the configuration attribute, and the notification message is generated and sent to the monitoring terminal by the target module when it determines that the updated configuration attribute is an emergency event; the shared memory is powered on when the monitoring terminal and any of the functional modules are powered on. Obtain the historical synchronization code of the target module, compare the consistency of the historical synchronization code with the current synchronization code to obtain the perception result, and update the historical synchronization code using the current synchronization code; the perception result indicates whether the target module has undergone configuration attribute updates.

2. The method of claim 1, wherein, The step of reading the synchronization code of the target module from shared memory in response to the received notification message includes: When the monitoring terminal is powered off, it is woken up and powered on in response to the received notification message, and after being woken up and powered on, it reads the synchronization code of the target module from the shared memory; When the monitoring terminal is powered on, it reads the synchronization code of the target module from the shared memory in response to the received notification message.

3. The method of claim 2, wherein, The notification message includes an identity identifier, and the step of reading the synchronization code of the target module from shared memory includes: Based on the identity identifier in the notification message, the target storage address corresponding to the target module in the shared memory is determined; Access the target storage address and read the synchronization code of the target module.

4. The method according to any one of claims 1-3, characterized in that, The synchronization code includes a configuration identifier and a checksum, and the bit width of the synchronization code is consistent with the bit width of the shared memory; the step of comparing the historical synchronization code with the current synchronization code to obtain a perception result includes: The historical configuration identifier in the historical synchronization code is compared with the configuration identifier in the synchronization code to obtain the comparison result; If the comparison results are inconsistent, the read check code is used as a check identifier, and the target check algorithm matching the target module is called to check the configuration identifier and the check identifier to obtain the check result; If the verification result is valid, the perception result is determined to be an update of the configuration attributes of the target module.

5. A configuration update awareness method, characterized in that, Applied to a functional module, the method includes: In response to an update of configuration attributes, a synchronization code is generated and written to shared memory; wherein, the shared memory is powered on when the monitoring terminal and any of the functional modules are powered on. When it is determined that the updated configuration attribute is an emergency event, a notification message is generated and sent to the monitoring terminal; the notification message is used to instruct the monitoring terminal to determine whether the configuration attribute in the functional module has been updated based on the synchronization code read from the shared memory.

6. The method according to claim 5, characterized in that, The synchronization code includes a configuration identifier and a checksum; generating the synchronization code includes: The configuration identifier is generated based on the update cycle of the configuration attribute; Invoke the target encryption algorithm that matches the functional module, and process the configuration identifier based on the target encryption algorithm to obtain the verification code; The synchronization code is generated based on the checksum and the configuration identifier; wherein the bit width of the synchronization code is the same as the bit width of the shared memory.

7. A configuration update sensing device, characterized in that, The device includes a reading module and a sensing module, wherein: The reading module is used to read the synchronization code of the target module from the shared memory in response to a received notification message; wherein the synchronization code is generated and written to the shared memory by the target module in response to an update of the configuration attribute, and the notification message is generated and sent to the monitoring terminal by the target module when it determines that the updated configuration attribute is an emergency event; the shared memory is powered on when the monitoring terminal and any of the functional modules are powered on. The perception module is used to obtain the historical synchronization code of the target module, compare the historical synchronization code with the current synchronization code to obtain a perception result, and update the historical synchronization code using the current synchronization code; the perception result indicates whether the target module has undergone configuration attribute updates.

8. A configuration update sensing device, characterized in that, The device includes a synchronization code processing module and a message processing module, wherein: The synchronization code processing module is used to generate a synchronization code in response to the update of the configuration attributes and write the synchronization code into the shared memory; wherein, the shared memory is powered on when the monitoring terminal and any of the functional modules are powered on. The message processing module is used to generate a notification message and send the notification message to the monitoring terminal when it is determined that the updated configuration attribute is an emergency event; the notification message is used to instruct the monitoring terminal to determine whether the configuration attribute in the functional module has been updated based on the synchronization code read from the shared memory.

9. A chip module, characterized in that, It includes multiple functional modules, a power supply module, a monitoring terminal, and shared memory, among which: The power module is used to supply power to the functional module, the monitoring terminal, and the shared memory module; The functional module, in response to the update of the configuration attribute, generates a synchronization code and writes the synchronization code into the shared memory; wherein, the shared memory is powered on when the monitoring terminal and any one of the functional modules are powered on; and when it is determined that the updated configuration attribute is an emergency event, a notification message is generated. The monitoring terminal, in response to the received notification message, reads the synchronization code of the target module from the shared memory; obtains the historical synchronization code of the target module, compares the historical synchronization code with the current synchronization code to obtain a perception result, and updates the historical synchronization code using the current synchronization code; the perception result indicates whether the target module has undergone configuration attribute updates.

10. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 4 or 5 to 6.

Images