Intelligent terminal management and control method and system based on dynamic configuration

Abstract

The application belongs to the technical field of intelligent terminal configuration management, and specifically discloses an intelligent terminal management and control method and system based on dynamic configuration, wherein the method comprises the following steps: obtaining a candidate configuration package, collecting a terminal capability baseline, a current active configuration and an initial operation evidence record, forming a transaction baseline sealing record, and appending a state change after a baseline cutoff serial number as an incremental operation evidence chain; constructing an evidence constraint configuration migration graph according to the candidate configuration package, the transaction baseline sealing record and the incremental operation evidence chain; and the technical problem to be solved by the application is how to complete configuration switching and actual loading confirmation according to a re-verifiable preceding state under the condition that the configuration state and the resource state of an intelligent terminal continuously change and configuration items have dependency and joint effect requirements, and determine a configuration recovery range meeting the dependency compatibility condition when execution fails or the terminal is restarted.

Description

Technical Field

[0001] This invention relates to the field of intelligent terminal configuration management technology, and specifically to an intelligent terminal control method and system based on dynamic configuration. Background Technology

[0002] In smart terminals, configurations are applied to various processing stages, including data acquisition, preprocessing, business analysis, result generation, and record management. Configuration items may have input-output dependencies, shared requirements, or resource usage conflicts. If a configuration changes its input size, output fields, or parameter interpretation, related processing stages need to use compatible configuration combinations. During configuration management, configuration package reception, planned generation, file writing, and actual loading occur at different times. The configuration status and resource occupancy status obtained during planned generation may change before submission. Simply checking if resources are idle at submission cannot identify situations where resources were occupied and then released during this period; merely replacing configuration files or confirming active configuration index updates does not indicate that the target system service has used the corresponding configuration to process input. When multiple files are used in the same configuration domain, if inactive configuration slots only save the content modified in the current session, configurations that need to be retained may be missed after switching. For cross-configuration domain dependency updates, even if each configuration domain completes index switching separately, intermediate version combinations may still not meet business interface requirements. After a verification failure, directly restoring the failed configuration may retain target configurations that depend on its output, or prevent the restored downstream configuration from receiving new upstream configurations. When the terminal restarts, historical loading records cannot directly represent the actual loading status of this startup. Therefore, it is necessary to link the configuration and running status on which the plan is based, resource authorization, complete configuration snapshot, actual loading verification, and post-recovery dependency compatibility conditions to determine the execution conditions and failure handling scope of each stage. Summary of the Invention

[0003] The technical problem to be solved by the present invention is: how to complete the configuration switching and actual loading confirmation based on the verifiable pre-state under the condition that the configuration state and resource state of the smart terminal are constantly changing and the configuration items have dependencies and common effects, and to determine the configuration recovery range that meets the dependency compatibility conditions when execution fails or the terminal restarts.

[0004] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: A method and system for managing intelligent terminals based on dynamic configuration includes: acquiring candidate configuration packages; collecting terminal capability baselines, current active configurations, and initial running evidence records to form transaction baseline sealing records; and appending state changes after the baseline cutoff number as an incremental running evidence chain; constructing an evidence-constrained configuration migration graph based on the candidate configuration packages, transaction baseline sealing records, and incremental running evidence chains; forming atomically visible configuration groups within the same atomic commit domain; establishing a group-level dependent directed acyclic graph; and generating an executable configuration plan containing expected pre-states and dependency compatibility conditions determined at compile time; writing a complete target configuration snapshot to an inactive configuration slot according to the executable configuration plan and performing a pre-check, pausing the affected configuration. The system responds to business inputs and cleans up in-transit tasks. It establishes resource release generation barriers for the managed resources involved and obtains exclusive commit credentials, forming a pending configuration group record. Based on the pending configuration group record, it verifies the pre-state and exclusive commit credentials under mutual exclusion protection, switches the active configuration index through atomic switching, and generates a version loading consistency evidence record based on the configuration readback result, the actual loading active configuration index sequence number of the target system service, and the behavior verification result. In case of failure, it determines the rollback configuration group set based on the group-level dependency directed acyclic graph, index switching status, and dependency compatibility conditions, and rolls back. After all configuration groups and dependency combinations pass verification or rollback verification passes, it saves the transaction termination record and restores the affected business inputs.

[0005] In one aspect of the invention, forming the transaction baseline archive record includes: Verify the platform digital signature, configuration list and file digest, applicable terminal conditions, system service version and configuration update sequence of the candidate configuration package, and extract the configuration status migration unit and its relationship record with unique identifier, read configuration item, modified configuration item, original configuration conditions and target configuration value; The terminal capability baseline is formed by collecting terminal device interface, atomic submission domain registration form, configuration structure and configuration slot capacity; the current active configuration is formed by reading the configuration item value, configuration list and immutable file location corresponding to the active configuration index; and the initial running evidence record is formed by collecting running task, resource usage, resource generation count, startup session and service instance information. After the relevant state event subscription is established, the state snapshot and baseline cutoff number are obtained through the state coordination lock. The terminal capability baseline, current activity configuration and initial running evidence record are associated with the current transaction identifier, configuration package summary and baseline cutoff number and persisted to form the transaction baseline archive record. Subsequent events generated during the baseline record persistence period are retained.

[0006] In one aspect of the invention, generating and using the incremental running evidence chain includes: Changes in resource usage, resource generation count, running tasks, target system service status, and activity configuration index after the baseline cutoff number are formed into evidence events, and the object identifier, state before change, state after change, state collection time and source, and instance identifier are saved. Add evidence events according to the event sequence number. The first evidence event is associated with the transaction baseline archive record summary. Subsequent evidence events are associated with the previous evidence event summary. When restoring the state, check the state before the change and the current restored state item by item. If they are consistent, apply the state after the change. The freshness of runtime evidence is checked based on the state collection time within the same startup session. For states that exceed the freshness threshold of runtime evidence, they are re-collected and state confirmation events are added. The chain prefix used for this compilation is fixed with the compilation deadline event number and summary. The corresponding plan is stopped when the event is missing, the summary is inconsistent, or the source instance changes.

[0007] In one aspect of the invention, forming the atomically visible configuration group includes: Based on the terminal capability baseline and compile-time runtime status, check the static admission conditions and dynamic execution conditions of the configuration state transition unit, record the resource occupancy status that can be released in a controlled manner as the execution waiting condition, and stop the current transaction when the necessary migration object does not meet the admission conditions. Check if dependent objects and co-effective objects are complete, and check for declared conflict relationships and whether the same configuration item is specified with different target values. If there are missing objects or configuration conflicts, stop the current transaction and execute the remaining configuration without deleting the necessary configuration state migration units. A set to be merged is formed based on mutually reachable dependencies and common effective relationships. When the set spans different atomic commit domains, the current transaction is stopped. When the set is in the same atomic commit domain, the configuration state migration units of the current transaction within that atomic commit domain are merged into an atomically visible configuration group.

[0008] In one aspect of the invention, generating the executable configuration plan includes: A group-level dependency graph is formed with atomically visible configuration groups as nodes and cross-group dependencies as directed edges. The commit order is determined by selecting configuration groups that do not have unprocessed predecessors in sequence. If there is a dependency cycle that cannot determine the commit order, the current transaction is stopped. Based on the compile-time configuration status and the target output of the predecessor group of this transaction, determine the expected prerequisite status of each group, and determine the dependency compatibility conditions based on the producer output interface and consumer input interface, and record the complete target configuration list, resource list, execution wait conditions, verification items and rollback rules; The configuration plan summary is generated by using group members, commit order, expected pre-state, dependency compatibility conditions, target configuration and verification content as plan content fields. The transaction identifier, transaction baseline archive record summary, compilation deadline event information, configuration slot position and source and target active configuration index sequence number are saved and verified as execution binding fields to form the executable configuration plan.

[0009] In one aspect of the invention, writing the complete target configuration snapshot to an inactive configuration slot and reading back the pre-check includes: According to the executable configuration plan, the update retention of the relevant configuration domains is obtained. The unmodified configuration is retained in the original configuration list and the addition, modification and deletion operations in the candidate configuration package are applied to form a complete target configuration list. The space required for the complete target configuration, configuration metadata and verification logs are checked and reserved respectively. Write the complete target configuration to a temporary file in the inactive configuration slot, and then perform file synchronization, atomic renaming and directory synchronization in sequence. At the same time, retain the original configuration snapshot and save the verification log in the transaction record area. Reread the complete target configuration, check the path, length and digest of each file, generate a configuration readback digest and compare it with the expected digest corresponding to the complete target configuration list. If the comparison is successful, record the write-ahead check pass status.

[0010] In one aspect of the invention, obtaining the exclusive submission credential and forming the pending configuration group record includes: When managed resources are effectively occupied, effectively released, or the device that causes the existing state to become invalid is reset, the resource generation count is updated. After the affected business input is suspended and the relevant tasks, device queues, and access references are cleaned up, a release stability check is performed to form the resource release generation barrier. In the mutual exclusion operation of the resource management service, the resource status, resource generation count and retention status are re-examined. If they pass, an exclusive retention is established, and an exclusive commit credential is generated that binds the resource identifier, resource generation count, start session identifier, resource management service instance identifier, current transaction identifier and configuration group identifier. The exclusive retention is maintained during the corresponding configuration loading and behavior verification. Generate an expected prerequisite state summary based on the fixed expected prerequisite states in the executable configuration plan. Persist the summary, configuration plan summary, configuration readback summary, execution binding field, exclusive commit credential identifier, and original configuration snapshot location to form the configuration group record to be committed. The records of the successor group are also associated with the valid version loading consistency evidence record of the predecessor group on which they depend.

[0011] In one aspect of the invention, generating the version loading consistency evidence record and performing a rollback includes: During the same mutual exclusion protection process, the source activity configuration index sequence number, current pre-state summary, configuration plan summary, execution binding field and exclusive commit credentials are checked. The activity configuration index is then updated through post-persistence updates, so that the target system service consistently reads the configuration snapshot corresponding to that index. After the target system service completes configuration parsing and establishes an active running object for processing verification input, it obtains the actual loading information bound to the running object, and generates a version loading consistency evidence record by combining the configuration readback result and the behavior result of the corresponding verification request. Upon failure, the switched failure group and the switched configuration group that depends on its output are added to the rollback configuration group set. The set is expanded according to the dependency compatibility conditions of the restored version combination. The original configuration is restored in reverse commit order, and the files, actual loading, and behavior results are verified. At the same time, a failure condition summary is generated based on the failure reasons and their dependency fields for subsequent duplicate commit judgment.

[0012] In another aspect, the present invention also relates to a smart terminal management and control system based on dynamic configuration, including a platform configuration management unit, a terminal management client, a runtime evidence collection unit, a configuration compilation unit, an inactive configuration slot pre-inspection unit, a resource generation management unit, a configuration submission unit, a version loading consistency verification unit, and a configuration rollback unit. The platform configuration management unit is used to generate and send candidate configuration packages, the terminal management client is used to verify candidate configuration packages and control configuration transaction status, and the running evidence collection unit is used to collect terminal capability baseline, current active configuration and initial running evidence records to form transaction baseline sealing records and incremental running evidence chains. The configuration compilation unit is used to check the configuration state transition unit and its relationship based on the candidate configuration package, transaction baseline archive record and incremental running evidence chain, form atomic visible configuration group and group-level dependency directed acyclic graph, and generate an executable configuration plan containing expected pre-state and dependency compatibility conditions. The inactive configuration slot pre-check unit is used to form a complete target configuration snapshot and complete write and readback pre-checks. The resource generation management unit is used to update the resource generation count, check resource release conditions, and obtain exclusive submission credentials. The configuration submission unit is used to control the affected business input, form a record of configuration groups to be submitted, and switch the active configuration index under mutual exclusion protection. The version loading consistency verification unit is used to verify the configuration content, actual loading information, and behavior verification results. The configuration rollback unit is used to determine the rollback configuration group set and perform rollback verification based on dependencies, index switching status, and dependency compatibility conditions.

[0013] In one aspect of the invention, the system further includes a terminal-side processor, volatile memory, non-volatile memory, active configuration slot, inactive configuration slot, system-level configuration service, resource management service, and target system service; The non-volatile memory is used to store programs, configuration snapshots, transaction baseline archive records, incremental execution evidence chains, executable configuration plans, pending configuration group records, active configuration indexes, version loading consistency evidence records, and transaction termination records. The system-level configuration service is used to manage configuration update retention and persistent index switching. The resource management service is used to maintain resource status and exclusive retention. The target system service is used to load configuration snapshots and return the actual loading information bound to the active running object. The terminal-side processor is used to execute the program to implement the method described in any one of claims 1 to 8, and after restarting, it first processes unfinished transactions based on the actual index, the configuration group record to be submitted, and the transaction termination record, then obtains the target system service loading confirmation in this startup, completes and writes the anti-rollback sequence required for the valid transaction completion record, and keeps the input paused for related services that cannot determine the valid configuration or cannot complete the recovery verification.

[0014] Compared with the prior art, the present invention has the following beneficial effects: This invention preserves the initial state of configuration transactions through transaction baseline sealing records and saves subsequent changes through incremental execution evidence chains, enabling configuration compilation to use state data with source and time correlation. Writing the expected pre-state determined during compilation into the executable configuration plan and re-checking the same configuration items upon commit helps identify relevant configuration changes that occurred after plan generation. Forming atomically visible configuration groups according to atomic commit fields and preparing complete target configuration snapshots preserves unmodified configurations, ensuring that configurations in the same group are selected by the same index switch. Resource release generation barriers and exclusive commit credentials combine resource change records with commit authorization, restricting resources from being occupied by other tasks between checks and switches. By pausing affected business inputs and separately checking configuration content, loading information corresponding to active running objects, and behavioral results, formal business can be restored in the verified configuration state. In case of failure, the rollback configuration group set is determined based on the occurred index switch and dependency compatibility conditions, handling directly failed groups, subsequent dependency groups, and related incompatible configurations caused by rollback. Transaction termination records save the final retained state, providing a basis for configuration selection and rollback prevention sequence completion after restart. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained from these drawings without creative effort.

[0016] Figure 1 This is a flowchart of a smart terminal management and control method and system based on dynamic configuration according to the present invention.

[0017] Figure 2 This is a flowchart of the sub-steps of step 1 in a smart terminal management and control method and system based on dynamic configuration according to the present invention.

[0018] Figure 3 This is a flowchart of step 2 in a smart terminal management and control method and system based on dynamic configuration according to the present invention.

[0019] Figure 4 This is a flowchart of step 3 in a smart terminal management and control method and system based on dynamic configuration according to the present invention.

[0020] Figure 5 This is a flowchart of step 4 in a smart terminal management and control method and system based on dynamic configuration according to the present invention. Detailed Implementation

[0021] The present invention will be further described below with reference to embodiments. The following embodiments are used to illustrate the composition, input data, processing order, configuration switching, result verification, and anomaly recovery process of a smart terminal management method and system based on dynamic configuration.

[0022] The smart terminal in this embodiment includes a processor, volatile memory, non-volatile memory, a communication interface, an active configuration slot, and an inactive configuration slot. The processor runs a terminal management client, an evidence collection unit, a configuration compilation unit, an inactive configuration slot pre-check unit, a resource generation management unit, a configuration submission unit, a version loading consistency verification unit, a configuration rollback unit, a system-level configuration service, a resource management service, and a target system service. A platform configuration management unit is located in a configuration management platform that communicates with the smart terminal, used to create candidate configuration packages and receive configuration transaction execution results. Each unit can be implemented by a program executed by the processor. The system-level configuration service and resource management service perform configuration file management and device access management through the interface granted by the terminal firmware. Ordinary running tasks do not have the permission to bypass the interface to directly open managed devices or rewrite managed configuration parameters; related access is registered by the resource management service.

[0023] In this embodiment, the capacity, index number, resource generation count, time, and verification results are setting data used to describe the processing procedure and do not indicate that the actual testing of the corresponding product model has been completed. During actual deployment, terminal capabilities and interface limitations are read from the target terminal, and statistical parameters are determined according to the limited-time testing method described later. Configuration management is limited to configuration items that can be reloaded through registered interfaces, whose actual loading status can be checked, and whose access to related tasks can be controlled. The online configuration loading in this embodiment is completed within an existing process instance of the target system service. Configuration items that require exiting the target system service process or a complete system restart to take effect are not included in the online configuration transactions of this embodiment.

[0024] An atomic commit domain is the configuration management scope registered by the system-level configuration service, and the configuration snapshot is selected by the same active configuration index. The atomic commit domain registry table stores the atomic commit domain identifier, configuration item key set, configuration slot location, and target system service list. It is a structured mapping record and does not have physical quantity units. Candidate configuration packages cannot expand the atomic commit domain on their own. The active configuration index is a persistent index record that stores the atomic commit domain identifier, active configuration index sequence number, configuration snapshot location, and configuration manifest summary. The active configuration index sequence number is the configuration snapshot identifier and is not equivalent to the configuration update sequence of the candidate configuration package; a newly assigned sequence number cannot be used for another configuration content, and during rollback, it allows reselection of the original configuration snapshot that is still retained.

[0025] Two configuration slots can be used alternately within the same atomic commit domain. The active configuration slot is pointed to by the currently active configuration index, while the inactive configuration slot is used to prepare the next complete target configuration snapshot. Files in the configuration slots retain their content unchanged while being indexed or referenced by rollback records, and verification logs are stored in the transaction record area. An atomically visible configuration group is a set of configuration state migration units that share one index switch within the same atomic commit domain in this transaction. In this implementation, one atomically visible configuration group is formed for each atomic commit domain within a transaction. After the index switch for the configuration group is completed, each target system service still needs to complete its configuration loading separately.

[0026] like Figure 1 As shown, the method of this embodiment includes the following steps: S1. Obtain and verify candidate configuration packages, collect terminal capability baseline, current active configuration and initial running evidence records, form transaction baseline sealing records, and append the state changes after the baseline cutoff number to the incremental running evidence chain.

[0027] S2 checks the admission conditions, dependencies, conflict relationships, and co-effectiveness relationships of configuration state migration units based on candidate configuration packages, transaction baseline archive records, and incremental operation evidence chains. It constructs an evidence-constrained configuration migration graph, forms atomic visible configuration groups and group-level dependent directed acyclic graphs, and generates an executable configuration plan that includes expected prerequisite states and dependency compatibility conditions.

[0028] S3 generates a complete target configuration snapshot based on the executable configuration plan and completes write and readback pre-checks, suspends affected business inputs and cleans up in-transit tasks, checks the release status of managed resources and obtains exclusive commit credentials, and persists the commit basis and rollback position as a record of the configuration group to be committed.

[0029] S4, based on the configuration group record to be submitted, verify the submission basis and switch the active configuration index under mutual exclusion protection, check the configuration readback result, the actual loading active configuration index sequence number of the target system service and the behavior verification result, and form a version loading consistency evidence record; after the verification is completed, save the transaction completion record, and if it fails, determine the rollback configuration group set and execute the rollback, and restore the business input or keep the relevant business stopped according to the transaction termination record.

[0030] In this embodiment, it should be noted that in S1, the candidate configuration package is a configuration update object sent by the platform. The terminal management client first checks its source, content, and applicable conditions before allowing subsequent processing. The terminal capability baseline is used to indicate which configuration structures the current terminal can interpret, which resources it can manage, and which configuration interfaces it can provide. The current active configuration is used to indicate the configuration snapshot actually selected by each atomic submission domain. The initial running evidence record is used to indicate the task, resource, and service status at the time of collection. These three types of data have different uses. Whether a resource is currently occupied cannot replace whether the device has the corresponding control capability, and the configuration file summary cannot replace the configuration item value that needs to be read later. The running evidence collection unit establishes an event subscription before taking a snapshot, obtains the snapshot and baseline cutoff number under the unified state coordination mechanism, and saves the changes after the cutoff number separately from the baseline. The transaction baseline sealing record saves the unmodifiable starting basis, and the incremental running evidence chain saves the state changes and state confirmation results afterward. The configuration compilation unit can therefore clearly identify from which point in time, which service instance, and which consecutive events the state used comes from, and does not directly treat a set of data with different collection times and no correlation as the same state. If baseline formation fails, candidate configuration package verification fails, or relevant status cannot be obtained, the current preparation will be terminated without modifying the activity configuration. The associated identifier in the record will be used throughout the subsequent planning, commit, and recovery processes, ensuring that each status comparison can locate its original record.

[0031] In this implementation, it should be noted that in S2, the configuration state transition unit is a structured record with defined configuration items, input conditions, and target values. Dependencies specify which transition unit provides the conditions required by a transition unit. The configuration compilation unit first checks whether the candidate configuration package contains complete transition objects, and then checks whether each configuration can be interpreted and executed by the current terminal. Resources temporarily used by a task are recordable waiting conditions and the corresponding transition unit cannot be directly deleted; if resource release cannot be controlled, co-effective objects are missing, or configuration item values ​​conflict, the current transaction cannot continue. Transition units that need to be co-effective or mutually dependent first undergo relationship checks, and then are merged according to the actual atomic commit fields. The sequential updates of several different indices cannot be described as a single index switch. After forming a group-level dependent directed acyclic graph, the configuration compilation unit determines the commit order and records read / write configuration items, expected pre-states, target configuration lists, resources, and verification items for each group. Cross-group dependencies also need to determine the conditions under which new and old configurations can be combined. The executable configuration plan therefore stores both the configuration content to be executed and the basis for allowing that content to be executed; changes that occur after the plan is formed need to be re-checked, and the current value cannot be retrieved again and directly replaced with the original expected value before submission. The configuration compilation result is used to generate subsequent write locations and verification lists, and cannot simply output a judgment of whether execution is allowed or not.

[0032] In this implementation, it should be noted that in S3, the inactive configuration slot is used to build a complete target configuration snapshot of the same atomic commit domain. Unmodified configuration items should also be retained; the entire configuration domain cannot be switched after only writing the changed files. Before writing, the configuration commit unit obtains the update retention of the configuration domain, checks that the original configuration used to build the snapshot is still valid, and then completes space reservation, file writing, directory synchronization, and file-by-file readback. The above-mentioned write-ahead check does not make the target configuration immediately available for business. When preparing to switch, the configuration commit unit suspends the reception of new input by the affected business according to the service connection relationship and waits for the already accepted tasks to finish using the original configuration, confirming that the device queue and access references have been cleared. The resource generation management unit observes whether the resources remain stably unoccupied based on the release check, and the resource management service then checks the current generation and establishes exclusive retention in the mutual exclusion operation. The configuration group to be committed records bind the originally planned expected state, target snapshot, resource authorization, and rollback position together. Configuration write-ahead completion, resource waiting completion, and record persistence completion are different processing results. Only when all these requirements are met will the current group enter the pending commit state. Groups without managed resources do not generate empty resource credentials, but configuration update retention and business input control are still performed. The files, resource authorization records, and expected states of inactive configuration slots respectively store the inspection results and are associated with the same transaction identifier.

[0033] In this implementation, it should be noted that in S4, the configuration submission unit first re-checks the preconditions based on the records of the configuration group to be submitted, and then updates the active configuration index within the same mutual exclusion protection scope, ensuring that other controlled configuration writes or resource occupancy cannot be interspersed between checks and switching. Selecting a new configuration snapshot for the index only proves that the configuration selection on the storage side has changed; the target system service still needs to parse the file, create a running object, and use that object for input verification. The version loading consistency verification unit associates file readback, the loading information corresponding to the running object, and the behavior verification results, distinguishing between file preparation, index switching, and actual use. When a group fails, the configuration rollback unit determines whether the group has been switched based on the actual index, first processing the failed group and subsequent groups that depend on its output, then checking whether the old and new configurations retained after rollback are compatible, and adding relevant upstream groups to the rollback scope if necessary. Rollback also includes configuration content, loading status, and behavior checks; simply restoring the index does not allow for service reopening. After all groups pass verification, the current service instance and cross-group combinations are checked, and the transaction termination record is persisted before business is restored. In the event of a power outage or recovery failure, the actual index and persistent records are used for processing, and the loading record of the old session is not used to replace the current running state. The starting point for processing all types of failures is determined based on the actual operations that have been executed. Groups that have not undergone index switching cannot be recorded as having been rolled back.

[0034] like Figure 2 As shown, in one specific embodiment, S1 includes the following steps: S11, receive candidate configuration packets, verify the platform digital signature, configuration list and file digest, terminal applicable conditions and configuration update sequence, and extract configuration state migration units and their relationship records.

[0035] S12 collects terminal capability baseline, current activity configuration, and initial operation evidence records from device information interface, system-level configuration service, resource management service, and target system service, and confirms the data source, service instance, and collection time.

[0036] S13, under the condition that the event subscription has been established, the state snapshot and baseline cutoff number are sealed, and subsequent state changes and state confirmation results are appended in sequence to form the transaction baseline sealing record and incremental operation evidence chain.

[0037] In this embodiment, it should be noted that for S11, the candidate configuration package includes a configuration package identifier, configuration update sequence, applicable terminal conditions, minimum system service version, configuration list, configuration state migration unit, dependencies, conflict relationships, co-effective relationships, verification inputs, verification judgment conditions, rollback required interface descriptions, digital signatures, and file digests. The platform configuration management unit creates the above content based on the configuration interfaces registered by the terminal. The configuration state migration unit corresponds to the configuration item change record, saving a unique identifier, reading configuration items, modifying configuration items, original configuration conditions, target configuration values, resource lists, and atomic commit field declarations. The output is a structured object that can be read by the configuration compilation unit and does not have physical quantity units. Dependencies reference the migration unit identifier that provides the preceding output, co-effective relationships reference the migration unit identifier that requires the target configuration to be selected together, and conflict relationships reference the migration unit identifier that cannot be executed simultaneously. Each identifier must be able to find a corresponding object in the candidate configuration package or the explicitly registered external configuration conditions; a text name lacking a source cannot replace the configuration object.

[0038] The terminal management client first reads the signature algorithm identifier and platform key identifier declared in the candidate configuration package, confirms that they are within the permitted range of firmware registration, and then calls the corresponding cryptographic interface to verify the signature. The signature input is a fixed-encoded configuration list and the digest of the files referenced therein; the signature field does not participate in the generation of its own signature input. The platform public key is written by the terminal's controlled initialization process and cannot be directly used if it is a public key provided by the candidate configuration package itself but not registered. The integrity check calculates the digest for each received file and compares it with the verified signature configuration list. The configuration package digest is generated based on the encoded content of the verified configuration list, which includes the digest of the referenced files. The signature field and the configuration package digest field do not participate in the calculation of the configuration package digest itself. The applicable terminal model, processor type, and system service version are checked against the terminal's return value. If the version contains multiple numeric segments, they are compared segment by segment. For example, if the subversion value of version 1.10 is 10, it is not determined to be lower than version 1.9 based on the entire string order. Duplicate migration unit identifiers, unresolved configuration fields, or target files outside the signature range will cause the candidate configuration package to fail verification.

[0039] The configuration update sequence uses a 64-bit unsigned integer, with the initial value provided by the terminal initialization record, for example, an initial value of 0. The valid rollback prevention sequence is the larger of the persisted rollback prevention sequence and the sequence required by the valid transaction completion record. Candidate configuration packets with lower sequences are rejected; those with the same sequence but different configuration packet digests are rejected; if both the sequence and digest are the same as the completed record, only the historical result of the transaction and the result of the check whether the current configuration still matches are returned, without re-switching the index. If the current configuration changes due to other completed transactions, the historical completion result is not represented as the current configuration still being the same. Candidate configuration packets with higher sequences continue to undergo subsequent admission checks; if a transaction fails, the rollback prevention sequence is not advanced.

[0040] In this embodiment, it should be noted that for S12, the terminal capability baseline stores the processor type, device interface, atomic commit domain registration table, configuration structure version, field type, allowed number of files, configuration slot capacity, file system synchronization capability, target system service loading capability, and resource control capability. Capacity is recorded as B, status capabilities are recorded as Boolean values ​​or enumeration values, and interface versions are recorded according to the field types specified by the interface. The current active configuration stores the active configuration index number, complete configuration list, configuration item value, original configuration verification list location and its summary, and immutable file location for each atomic commit domain. Referenced original configuration snapshots are retained to prevent subsequent cleanup from affecting plan compilation and rollback. The initial running evidence record stores the running task identifier and status, resource occupant, resource generation count, startup session identifier, resource management service instance identifier, target system service instance identifier, running object identifier, target system service actual loading active configuration index number, and status collection time. Configuration item values ​​are used for precondition comparison, file locations are used to read actual content, and summaries are used to check content consistency; these data cannot be substituted for each other.

[0041] The startup session identifier is a combination of a persistent startup count and a 128-bit random number generated by the operating system's random number interface. Each startup updates the startup count before the configuration service accepts a transaction; no new transaction is established if random number generation fails or the count range is exhausted. The resource management service and the target system service generate instance identifiers when the process instance starts, used to identify situations where a system reboot has not occurred but the service has already restarted. The data source identifier corresponds to the system service identity registered in the firmware. The evidence collection unit reads data through a controlled communication interface and verifies the identity of the calling peer. When the active configuration index, file digest, and actual loaded active configuration index number of the target system service within the atomic commit domain are inconsistent, a recovery check of the existing configuration is performed first; a new online configuration plan is not compiled using this inconsistent state.

[0042] The evidence freshness threshold is obtained through a limited number of state-based acquisition tests; in this example, it is set to 500ms. Specifically, the acquisition latency is recorded under normal load, processor utilization of 80%, and storage write load of 90%. Processor utilization is obtained by comparing busy time with available processing time within a 1-second statistical window. Storage write load is obtained by comparing actual write throughput within the same window with the pre-measured continuous write throughput of the device. 1 second is the statistical window used in this example's capability test interface. A total of 10,000 valid acquisition latencies are sorted from smallest to largest. The position is determined by multiplying the sample size by 99% and rounding up, taking the 9900th value. Assuming this value is 382ms, and the maximum observed value in the additional scheduling latency record is 118ms, the sum of these two values, 500ms, is used as the example threshold. This method is used to determine when to refresh the evidence; the relevant state is still re-checked upon submission.

[0043] Status acquisition time is obtained from a monotonic clock within the same startup session and recorded in milliseconds. Freshness is determined by subtracting the actual acquisition time from the time the status was used; the platform sending time or log write time is not used as a substitute for the acquisition time. Historical change events are used to illustrate past status transitions. Even if the current status remains unchanged for a long time, a status confirmation event can be generated through a new status query. Status is re-acquired after a restart, without calculating time differences across startup sessions. When the source interface cannot provide a consistent time base, the terminal records the status read time at the controlled acquisition entry point and associates it with the source version; unaligned source times cannot be directly mixed.

[0044] In this embodiment, it should be noted that for S13, the system-level configuration service and resource management service use a shared state area subject to access control, in which a state coordination lock and event sequence number counter are set. Controlled configuration changes related to transactions, resource access registration, and service loading status publication are all modified and events are registered under this coordination mechanism. The running evidence collection unit first subscribes to events, then acquires the state coordination lock, copies the current configuration snapshot position and running state to the transaction buffer, and reads the current event sequence number as the baseline cutoff sequence number. Subsequently, it releases the lock and persists the transaction baseline archive record. The file content is read through the retained immutable snapshot, and the entire file is not copied during the lock holding period. Events occurring after the baseline cutoff sequence number and before the baseline record persistence is completed are entered into the event buffer, and then appended in sequence after the baseline record is completed. When the buffer space is insufficient or the source report event is lost, the current baseline establishment process is terminated, but events are not omitted and the system continues to use the system.

[0045] The transaction baseline archive record is an append-only record of the transaction start, including the transaction identifier, record version, configuration package summary, session start identifier, baseline end sequence number, terminal capability baseline, current active configuration, initial runtime evidence record, and integrity verification information. Larger configuration contents are referenced through preserved immutable file locations and summaries; the record itself does not use a summary to replace all status fields. The events in the incremental runtime evidence chain include event sequence number, object identifier, event type, pre-change state, post-change state, state acquisition time, event occurrence time, source and instance identifier, event content summary, and preceding summary. The first event references the transaction baseline archive record summary, and subsequent events reference the previous event summary; their own summary fields are not included in their own summary calculations. Re-acquisition of the same state can also form a status confirmation event; its pre-change state is the same as its post-change state, but it has a new acquisition time.

[0046] The configuration compilation unit checks the pre-change state of an event against the current restored state according to the event sequence number. If they match, the post-change state is applied, forming a compile-time runtime state for S2. For example, if the baseline cutoff sequence number is 100 and the resource generation count is 40, and event 101 records that the resource changes from occupied to unoccupied and the generation count changes from 40 to 41, then the restored result is updated to unoccupied and generation 41. If a subsequent event declares that the pre-change generation count is 42, but the current restored result is still 41, then the difference cannot be skipped and execution cannot continue. The chain prefix used for this compilation is fixed by the compilation cutoff event sequence number and its summary, and subsequent appended events will not change this prefix. If an event is missing, the preceding summary is inconsistent, the source instance changes, or the state is inconsistent, the current plan is stopped, and a new baseline is obtained after completing the necessary processing for the existing switch.

[0047] like Figure 3 As shown, in another specific embodiment, S2 includes the following steps: S21, determine static admission conditions, dynamic execution conditions, and execution waiting conditions based on the terminal capability baseline, candidate configuration packages, and compile-time runtime status, and check the integrity of the migration object and configuration conflicts.

[0048] S22, establish an evidence-constrained configuration migration graph according to the configuration state migration unit, form an atomically visible configuration group based on mutual dependencies, common effectiveness relationships and atomic commit domains, and check whether the target state within the group is consistent.

[0049] S23. Based on cross-group dependency relationships, establish a group-level directed acyclic graph of dependencies, determine the commit order, expected prerequisite states and dependency compatibility conditions, and generate an executable configuration plan and a configuration plan summary.

[0050] In this implementation, it should be noted that for S21, the static admission conditions are derived from the applicability requirements of the candidate configuration package and the terminal capability baseline, including at least the matching of configuration interfaces, file structures, field types, storage requirements, and related service functions. Dynamic execution conditions are derived from the compile-time runtime state, including whether the current configuration meets the original configuration conditions, whether the actual loading activity configuration index number of the target system service matches the current activity configuration index, whether related tasks support controlled pause, and whether resource status is verifiable. If a resource is currently occupied by a task but can be released after the task ends, the release conditions and required resources are recorded, and the migration unit is not deleted from this transaction. If the configuration content cannot be read, the actual loading activity configuration index number of the target system service cannot be confirmed, or resource access cannot be managed, the current transaction is stopped. All migration units in the candidate configuration package are considered necessary objects for this request; if any necessary object does not meet the static admission conditions, the remaining configuration after deleting that object is not executed.

[0051] The configuration compilation unit checks each dependency to see if a corresponding provider exists. For input conditions other than candidate configuration packages, it reads the registered external configurations and interface descriptions and adds these configurations to the reading scope. Co-effective relationships must reference valid migration units in the current transaction. Conflict checking first determines if both sides of a declared conflict are selected, then compares whether the same configuration item in the modification list is assigned different target values; if a conflict is found, it outputs the conflict object and configuration item and stops. When different units assign the same type and target value to the same configuration item, the dependency information of each unit is retained, but only one copy of that configuration item is generated in the complete target configuration list. The target configuration value should be determined by the content of the candidate configuration package and explicit original configuration copying rules; it cannot retain pending values ​​that rely on unpublished calculations.

[0052] In this embodiment, it should be noted that for S22, the evidence constraint configuration migration graph is an adjacency record generated by the configuration compilation unit. Nodes store configuration state migration units and their admission check results. Dependency directed edges point from the unit providing the preceding output to the unit using the output. Conflict relationships and co-effective relationships are stored separately in the relationship table and are not mixed as dependency directed edges. The configuration compilation unit establishes a queue to be checked starting from each node, adds the successors of that node to the queue sequentially, registers the visited flag when a node is removed, and then adds the unvisited successors until the queue is empty, obtaining the set of reachable nodes. When two nodes are mutually reachable, they are grouped into the same set to be merged; sets connected by co-effective relationships continue to be merged, repeating until the set members no longer change. The transaction stops when any set involves different atomic commit domains; otherwise, all migration units of this transaction within the same atomic commit domain are grouped into an atomically visible configuration group, with the group identifier formed by the identifier of the migration unit at the top of the group. The graph and group member table are used to determine the order in S23 and do not have physical quantity units.

[0053] Interdependent units can be grouped together if their target configuration values ​​are determined and the combination of target values ​​satisfies interface constraints. For example, if the model input configuration and normalization configuration require the use of the same set of interface parameters, and the candidate configuration package has given the target values ​​for both and they are managed by the same active configuration index, they can jointly select a target snapshot. If the model configuration belongs to the analysis processing atomic commit domain, the normalization configuration belongs to the video processing atomic commit domain, and the candidate configuration package requires both to take effect from the same index switch, then the current transaction cannot be executed. Simply dividing the candidate configuration package into two packages will not change this requirement. When ordinary output dependencies cross configuration domains, the order can be determined according to S23, and controlled loading and verification can be completed while the relevant business inputs remain suspended.

[0054] In this implementation, it should be noted that for S23, the configuration compilation unit establishes each atomically visible configuration group as a group-level node, converts cross-group dependencies into group-level directed edges and deletes duplicate edges, and counts the number of unprocessed predecessors for each group. Each time, from groups with zero predecessors, the group with the highest-ranking identifier is added to the commit order, edges from that group are deleted, and the predecessor count of subsequent groups is updated, until all groups are retrieved. If there are still groups that have not been retrieved but do not have any groups with zero predecessors, a dependency cycle is formed after the current grouping, the transaction is stopped, and the relevant group identifiers are saved. The absence of a cycle before merging by atomic commit domain does not mean that a cycle will still be absent after merging; therefore, the sorting check is performed after grouping is complete. The resulting group-level dependency directed acyclic graph stores group members, cross-group dependencies, and topological order, serving as input for S3's configuration preparation and S4's determination of dependency fallback direction.

[0055] The expected preceding state is a condition table of configuration items saved in the executable configuration plan, containing information from the baseline and state restoration results prior to the compilation deadline. Each group's read scope includes configuration items it reads and modifies, configuration items involved in dependent inputs, and interface interpretation parameters. Fields dependent on the output of the predecessor target of this transaction use the predecessor group's target value as the expected value, and the predecessor group is required to form a valid version loading consistency evidence record before the current group commits. Other fields use values ​​determined at compile time and are not allowed to be directly overwritten after rereading in S3. Each field stores its atomic commit domain, configuration item key, data type, and value. If a configuration item does not exist, a non-existent type flag is stored, not replaced by an empty string. The configuration commit unit sorts, encodes, and calculates the expected preceding state summary by domain identifier and configuration item key. S4 rereads the same field range and calculates the current preceding state summary using the same rules.

[0056] Dependency compatibility conditions are records of allowed combinations between producer output and consumer input. Input comes from registered interface descriptions, configuration content, and verified version combination tests. Output is a condition table that can be evaluated item by item. Data size, data type, channel order, field name, field meaning, and normalized interpretation must be compatible; semantic requirements cannot be inferred solely from identical file formats. Version combinations without corresponding interface descriptions or verification criteria are treated as incompatible. For example, if the old preprocessing configuration is only used with old model parameters, and the new preprocessing configuration is only used with new model parameters, the two corresponding combinations are registered as allowed, and the two cross combinations are registered as disallowed. Transactions are stopped when the final target combination is disallowed; temporary cross combinations only exist during business input pauses and cannot process formal business. Services outside the candidate configuration package that use related outputs also participate in the check, and the same condition table continues to be used during configuration rollback.

[0057] An executable configuration plan is a structured record containing plan content fields and execution binding fields. Plan content fields include group members, logical commit order, read / write configuration items, expected pre-states, target configuration list and summary, execution wait conditions, dependency compatibility conditions, validation items, time parameters, and rollback rules, used to calculate the configuration plan summary. Execution binding fields include transaction identifier, transaction baseline archive record summary, compilation deadline event number and summary, original configuration snapshot location, actual write location, source active configuration index number, and target active configuration index number, which are stored and checked separately and are not included in configuration plan summaries used to identify identical plan content. The target active configuration index number is assigned and registered by the system-level configuration service; assignment does not change the current active configuration. When the plan content changes, recompilation is performed; when the binding fields change, the original pending configuration group record can no longer be used.

[0058] This implementation uses SHA-256 to generate the digest, with the output length defined as 32 bytes by the operation. The encoding rule version is saved with the record. Configuration key uses the registered UTF-8 byte string and is sorted byte-wise. Each field stores a type flag, length, and content. Integers are stored according to the specified length and big-endian byte order, strings store UTF-8 content, Boolean values ​​use the specified values, arrays are stored according to the interface order, and sets are sorted first. Floating-point fields use binary representation with the precision specified by the interface and do not accept non-numeric or infinite values. In this example, the encoding version specifies that the type flag occupies 1 byte, the length field occupies 4 bytes and is stored in big-endian order, and the length indicates the number of bytes in the field content. Signed integers use 8-byte two's complement, and unsigned integers use 8-byte unsigned representation, with different type flags. Boolean content uses 1 byte of 0 or 1, and the length and precision of floating-point content are stored according to their type. The decoding end uses the same version definition; unknown types, duplicate keys, and length mismatches are all rejected. Integer 1 and string 1 have different types and do not generate the same encoded input. Transaction identifier, event time, temporary file name, and newly allocated index are not included in the calculation input of the configuration plan summary through indirect fields such as baseline summary. Records with their own summaries are excluded from the summary calculation.

[0059] like Figure 4 As shown, in another specific embodiment, S3 includes the following steps: S31, based on the executable configuration plan, obtain the update retention of the relevant configuration domain, build a complete target configuration snapshot, complete capacity, path and permission checks, write to the inactive configuration slot and generate a configuration readback summary.

[0060] S32, suspend affected business inputs, clear in-transit tasks and device queues, update and check resource generation counts, establish resource release generation barriers and obtain exclusive commit credentials for the current configuration group.

[0061] S33, read the fixed expected preceding state in the executable configuration plan, associate its summary with the target snapshot, execution binding field, exclusive commit credentials and rollback configuration position, and persist it as a pending configuration group record.

[0062] This implementation first performs snapshot pre-writing on all configuration groups. The group preparation operations involving credentials and pending submission records are executed sequentially with the group submission verification operations in S4. After the predecessor group passes verification, credentials are obtained for the successor group, and pending submission records are generated. The successor group uses the predecessor version loaded with consistency evidence records as its preparation basis. Update retention of relevant configuration domains and the pause status of affected business inputs cover this continuous processing, preventing the premature issuance of credentials that may become invalid due to predecessor resource usage to all successor groups.

[0063] In this implementation, it should be noted that for S31, the configuration update retention is a transaction occupancy record saved by the system-level configuration service, indicating that the specified configuration domain can only be written to by the controlled configuration of this transaction before the end of the current transaction. The application scope includes the configuration domain to be modified this time and the external pre-configuration domain that needs to remain unchanged. The service checks whether the scope conflicts with other update retentions within the state coordination lock, and registers the transaction identifier after passing the check; if a conflict occurs, the current plan stops preparation and waits without holding a portion of the configuration domain. After obtaining the retention, the original configuration snapshot is re-compared with the execution binding field, and the old plan is stopped if there are changes. The complete target configuration snapshot first copies the retention file according to the original configuration list, and then performs the add, modify, and delete operations of the candidate configuration package declaration. Unmodified configurations cannot be omitted. The expected target configuration list consists of the original configuration file summary and the verified target file summary. The list records the path, length, data type, and summary, but does not include verification logs.

[0064] Capacity and file quantity limits are read from configuration slot quotas, available file system space, and the target service capability interface. For example, if the capability interface returns a limit of 128 configuration files, and there are 7 business configuration files and 1 configuration manifest file, then it is checked as 8 files, and the 7 migration units are not directly considered as the total number of files. Required space is calculated based on the complete snapshot, configuration manifest, transaction metadata, actual file allocation space, and verification log reservations. Space still referenced by active indexes, rollback records, or other unfinished transactions cannot be counted as free. Independent quotas are compared separately for each domain; if reservation fails, the process stops. Allowed paths and permissions are derived from the directories and service identities registered in the firmware. The path normalization result, directory ownership, write permissions, and target service read permissions are checked, and writing to locations outside the allowed range via directory jumps or symbolic links is rejected.

[0065] During writing, a temporary file is created in the currently inactive configuration slot. After data writing and file synchronization are complete, the file is atomically renamed, and then the parent directory is synchronized. Renaming the temporary file for the same file will not generate another file's content, but capacity checks still include other files retained simultaneously. After reading back file by file, the path, length, and content summary are compared, and a complete configuration list summary is reconstructed. This summary is then compared with the expected summary specified in the plan to obtain the configuration readback summary and write-ahead check results. If file parsing, synchronization, readback, or permission checks fail, the index is not switched; only writes that can be confirmed to belong to the current unreferenced data are cleaned up. The original configuration snapshot continues to be retained until the transaction ends or rollback verification is completed and cannot be overwritten due to changes in configuration slot roles.

[0066] When model files are involved, the preflight check calls the target runtime library without accessing the managed hardware's structure resolution interface. It reads the model format, operator requirements, fixed input size, output structure, and working area requirements, checks for compatibility with installed runtime libraries and device capabilities, and attempts to allocate the necessary host memory. Actual loading and computation on the device side occur after resource authorization is obtained; failures are handled according to S4 procedures. Storage capacity checks and runtime memory checks are recorded separately. The ability to write model files does not guarantee runtime buffer allocation; passing the host memory preflight check does not replace device-side loading verification. This process uses existing model files and installed runtime libraries carried in the candidate configuration package and does not generate new training models.

[0067] In this implementation, it should be noted that, for S32, the configuration submission unit determines the affected service scope based on the registered service input / output connections and dependencies, sets a pause flag at the input entry point, refuses to accept new service inputs, and returns a paused state to the caller. Accepted inputs continue to be processed using the original running object. After the device stops receiving new acquisition or processing tasks, it waits for existing device operations to return to a completed state, the pending queue to be cleared, the running task to exit the corresponding access area, and the access reference to be released; it does not directly discard accepted tasks. Configuration is not switched if a pause confirmation or clearing result cannot be obtained. Verification tasks use a separate verification entry point, while normal service entry points remain paused during subsequent configuration group processing. Services without device resources within the scope must also confirm the completion of in-transit tasks; services outside the scope without related dependencies do not participate in this pause.

[0068] The preparation wait threshold is used to limit the wait time for one business process runout and the current group's resource request. In this example, it is set to 10,000 ms. This threshold is derived from the limited number of preparation tests allowed under the task type that allows configuration updates and the business's allowed wait requirements. The test starts from issuing the pause and release request and ends when the required task runout and all resource reservations are established, recording 100 valid durations. Assuming the maximum value is 9,200 ms, and the business interface allows a maximum wait of 10,000 ms for one preparation request, this example uses 10,000 ms. A deadline is registered when the current group begins preparation. If all preparation conditions are not met within the deadline, the request is cancelled. Failures prior to index switching cancel preparation; if other groups have already switched, the process is transferred to S4 failure handling. This threshold is not used as the total time limit for all configuration groups to complete.

[0069] The resource generation count is a 64-bit unsigned integer stored by the resource management service for each managed resource, without a physical unit. Each valid occupancy, valid release, or device reset that invalidates the original resource state increases the count; rejected occupancy requests do not increase the count. New authorizations cease when the count can no longer increase, and the wrapped-back value is not used for old credentials. The resource release generation barrier is a record-based check result, with the release status returned by the task and driver as input. It stores the resource identifier, the count at release completion, the session initiation identifier, the resource management service instance identifier, and the stable observation start point for subsequent credential requests. Exclusive reservations only prohibit other access and are not equivalent to a single device occupancy; therefore, establishing a reservation will not impersonate a device operation to change the release count.

[0070] In this example, the stable resource release threshold is set to 200ms, derived from a limited number of resource release calibrations. Each time, the times of issuing the release command, clearing the device queue, completing the issued operation, and completing the access reference cleanup are recorded. The latest completion time of the latter three is taken as the actual release completion time. The processing times of 10,000 release operations are sorted, and the 9900th value is taken as the 99th percentile; assuming this value is 146ms, and the maximum observed additional scheduling time is 54ms, the sum is 200ms. During runtime, the actual release must be confirmed first, and then the resource must be continuously observed to ensure it is not occupied and its generation count remains unchanged within 200ms. This time is used for stability observation and does not replace device completion and reference cleanup confirmation; if the resource is occupied again during the observation period, it must wait for release again.

[0071] After a stable observation period, the resource management service, within the state coordination lock kernel, checks the current state, generation count, instance, and existing reservations. If the conditions are met, it registers the exclusive reservation for the transaction and returns an exclusive commit credential; otherwise, no credential is issued. Multiple resources are sorted by resource identifier, and a successful application requires all of them to be satisfied. If the application fails, the partially obtained reservations are revoked. The exclusive commit credential is a structured authorization record of the server's stored state, containing the credential identifier, resource list and corresponding generation, session initiation identifier, resource management service instance identifier, transaction identifier, configuration group identifier, and operation purpose. Tasks without the corresponding authorization cannot obtain resources through the resource access entry. A commit cannot be made if the client only possesses a credential text and the server has no valid authorization record.

[0072] In this embodiment, it should be noted that for S33, the configuration group record to be submitted takes the executable configuration plan, write-ahead check result, and current group authorization result as input, and outputs a persistent submission basis. The record saves the transaction identifier, configuration group identifier, atomic commit field identifier, original configuration snapshot location, expected preceding state and its summary, configuration plan summary, configuration readback summary, source active configuration index number, target active configuration index number, compilation deadline event information, and exclusive commit credential identifier. When preparing a successor group, the version load consistency evidence record identifier of the predecessor group it depends on is also saved; successor preparation stops when the predecessor evidence fails. The configuration commit unit reads the expected value already determined by the plan, and cannot replace the value with the currently read configuration value to eliminate inconsistencies. Only after the configuration group record to be submitted completes file and directory persistence is the current group recorded as pending submission; if only write-ahead is passed but valid authorization or record persistence result is lacking, it is not eligible for submission.

[0073] Once a credential is used for the first time in a corresponding index switch, it becomes active and is no longer allowed to be used for another forward switch. However, exclusive retention continues to overwrite loading and behavior verification. Verification tasks access resources according to the authorization of this transaction, and the resulting valid occupancy and release continue to update the generation and associate task identifiers; these authorization changes are not treated as preemption by other tasks, nor are they allowed to be switched again using old credentials that have already been used. Retention is released after successful group verification. If a failure requires rollback, the verification tasks for this group are first stopped and cleaned up. A new credential for the rollback purpose is generated according to the current generation while maintaining the retention of this transaction. Predecessor groups that have already released retention are re-applied for during rollback. After process exit, service instance changes, or credential revocation, further commits are stopped, incomplete operations are confirmed, and recovery processing begins; business entry points are not directly opened.

[0074] like Figure 5 As shown, in another specific embodiment, S4 includes the following steps: S41, under mutual exclusion protection, verify the pre-state, configuration plan, execution binding fields and exclusive submission credentials in the configuration group record to be submitted, and persist the switching active configuration index after the verification is successful.

[0075] S42, reread the target configuration and check the active running objects of the target system services, obtain the behavior verification results through the corresponding verification request, and generate version loading consistency evidence records.

[0076] S43 performs a joint check on all configuration groups before the transaction ends. If the check passes, the transaction completion record is saved and the rollback prevention sequence is updated. If the check fails, the rollback configuration group set is determined, the rollback verification and failure handling record are completed, and the business recovery and restart recovery are handled according to the transaction termination record.

[0077] In this implementation, it should be noted that, for S41, after the configuration submission unit acquires the state coordination lock, it checks the current transaction configuration update retention, source active configuration index sequence number, target configuration location, configuration plan summary, execution binding field, and exclusive submission credential status from the shared state area, and regenerates the current preceding state summary for the specified configuration items, comparing it with the expected preceding state summary in the record of the configuration group to be submitted. The target value of the predecessor group belongs to the expected change declared in this plan; other configuration changes not accepted by the plan cause the comparison to fail. The original credential cannot be used when there is inconsistency between resource generations, startup sessions, or resource management service instances. The check and index update are in the same mutually exclusive protection process; resource access entry points and other configuration writes also use this coordination mechanism, and another controlled occupancy cannot be inserted after the check passes. When the mutex lock holding process exits abnormally, the takeover process first processes the unfinished transactions and does not use the check results before the abnormal exit as the basis for continued switching. Operational anomalies such as equipment failures are handled by subsequent loading and verification checks; the service entry point remains suspended during this period.

[0078] The index record stores the atomic commit domain identifier, active configuration index sequence number, configuration snapshot location, complete configuration manifest summary, transaction identifier, configuration group identifier, and record summary. After the system-level configuration service confirms that the target snapshot and the configuration group record to be committed have been persisted, it writes a temporary index record to the same file system as the current index, completes file synchronization, atomically renames and replaces the current index record, completes parent directory synchronization, and only then issues a mount notification. The file system must support these operations; the same result cannot be presumed on storage interfaces that do not support directory synchronization or atomic replacement. If an error is returned or the operation result is uncertain, the actual index is read and compared with the original and target records; records that have already been switched are included in the failure handling; if the result is still uncertain, the service remains suspended and transitions to recovery. A new index switch will not begin if the log space cannot cover the current switch status and corresponding rollback records.

[0079] Configuration group status is represented by appended records, including write-ahead check passed, pending commit, index switched, verification passed, rolling back, rolled back, and rollback failed. Groups whose indexes have been switched but verification failed still need to be rolled back; they cannot be ignored simply because they haven't entered the verification passed state. If the pre-verification fails and the index hasn't been switched, the pending commit records for this group are canceled. If other groups have been switched in the current transaction, check according to S43 whether these groups need to be restored. Relevant changes are appended to the incremental execution evidence chain. A new baseline and plan are established only after the old transaction is processed, and the original sealed records are not modified before committing.

[0080] In this embodiment, it should be noted that for S42, after receiving the load request, the target system service reads the active configuration index once. During this load, the corresponding configuration snapshot is used consistently, and the index is not reselected when reading different files. After the service completes configuration parsing, field checking, and running object creation, it sets the new object as the active running object for processing verification input, and then publishes the actual load active configuration index sequence number of the target system service, along with the service instance identifier, running object identifier, and the configuration summary used. Receiving a load request, opening a file, or reading a new index does not indicate that the load has been completed. The version load consistency verification unit first reads back the target snapshot and verifies the configuration readback summary, then checks the active running object information of each target system service, and then sends verification input with the current request identifier. The response should carry the same request identifier, service instance identifier, and actual processing object information; a late old response cannot replace the current response.

[0081] In this example, the target system service loading completion threshold is set to 3000ms, derived from a limited number of reload tests covering both the original and target configurations. Each loading request begins after the active configuration index is persisted and ends when the service returns confirmation that the target running object used for verification processing has been loaded. The 600 valid durations are sorted, and the 594th value is taken as the 99th percentile. Assuming this value is 2310ms, and the maximum observed additional scheduling latency is 690ms, the sum is 3000ms. The verification unit subscribes to the loading completion event and queries the current loading information once more before the deadline. If the target status is still not obtained, a timeout is determined. Reading the original sequence number before the deadline only indicates that confirmation has not yet been made, and does not immediately indicate failure. When multiple services are involved, confirmation is made one by one, with each service's waiting time starting from the time its respective loading request is issued.

[0082] In this example, the behavioral verification response threshold is set to 800ms. This threshold is derived from a limited number of end-to-end call tests covering the verification inputs required for both the original and target configurations. Each time a verification request is sent to the target service interface, until the complete response for the same request is returned, 1000 valid durations are sorted, and the 990th value is taken. Let's assume this value is 613ms, and the maximum observed latency for additional processing and communication scheduling is 187ms; then, these are added together to obtain 800ms. The time the request enters the interface and the complete response return time use the same monotonic clock. Whether the response is completed within the deadline is determined by this clock record. Responses exceeding the threshold, missing fields, mismatched request identifiers, or mismatched running object versions all fail, and partial responses cannot be considered complete. The above time data is an example value; in actual deployments, corresponding load, version, and test records should be retained.

[0083] The validation input and judgment conditions are carried by the candidate configuration package. The input file has a summary, and the field types and coordinate explanations are from the business interface description. The categories and locations are from pre-annotated and verified samples. For example, the cropped validation image is 640 pixels by 640 pixels. The labeled scratch category is 3. The expected defect area has a left boundary of 100 pixels, a top boundary of 80 pixels, a right boundary of 140 pixels, and a bottom boundary of 100 pixels. The origin of the coordinate system is the top left corner of the cropped image. The allowable error for the coordinates is 2 pixels in this example. This error comes from the difference between the validation output (verified correctly by manual review) and the labeled boundaries after a limited number of manual verifications. The maximum single boundary difference is set to 1.6 pixels, rounded up to 2 pixels. The errors of each boundary are compared separately, and the boundary order and image range are checked. The categories must match. The model file is executed by the installed runtime library according to the determined input size, type, and channel order. This method does not train the model, nor does it directly set the correct answer based on the model's single output.

[0084] Verification calls use a separate entry point. The generated device control content, content to be uploaded, and deletion operations first enter the verification output buffer, are not sent to the actual execution device, are not used as formal test records, and are not deleted from the original business records. Background upload and cleanup tasks generated after the target configuration is loaded are also constrained by the business pause flag. Before the transaction ends, only the content to be executed is registered, and no corresponding external operations are performed. The target service should execute the same configuration parsing and field generation logic as the running object of this activity, only retaining the results before executing external operations. After configuration reading, all service loading, and specified behavior items have all passed, a version loading consistency evidence record is generated, saving the transaction identifier, configuration group identifier, atomic commit domain identifier, active configuration index sequence number, configuration readback summary, identifiers of each service instance and running object, actual loading active configuration index sequence number of each target system service, verification request identifier, behavior result, start session identifier, and verification time. This group is added to the set of verified configuration groups. Before the next group prepares to use this record, it is checked that its corresponding configuration and service instance are still valid.

[0085] In this implementation, it should be noted that for S43, after all groups have passed group-by-group verification, the configuration submission unit re-checks the current domain indexes, configuration summaries, service instances, running object identifiers, and cross-group dependency compatibility conditions to confirm that there have been no changes in the state that invalidated the group after verification. After passing verification, the transaction completion record is persisted, and the configuration package summary, final index set, version load consistency evidence record association information, and the rollback prevention sequence to be adopted are saved. The independently saved rollback prevention sequence is then updated. If the record persistence result is uncertain, the service remains suspended and enters recovery processing, without simultaneously executing rollbacks that may contradict valid completion records. Before resuming input, the service readiness is confirmed again. If the completion record is valid but the service is invalid at this time, the completed target configuration is reloaded; completed transactions cannot be treated as incomplete transactions and rolled back.

[0086] If any check fails, confirm which groups have been switched using the actual index. Add switched groups to the rollback configuration group set, and cancel pending commits for groups that have not yet been switched. Access each group sequentially along the output dependency direction, adding switched groups that depend on the failed groups to the set, and stopping preparation for unswitched successors. Then, assuming that groups within the set restore their original configurations and groups outside the set maintain their current configurations, check all dependency compatibility conditions for affected services in each plan. This check is also performed when the rollback configuration group set is empty. If retaining the target configuration would be incompatible with the restored adjacent configurations, add the switched groups involved in this transaction to the set, and continue adding its switched successors, repeating until no more are added. Each group is added only once, and the set will not exceed the number of switched groups in this transaction. If there are no external incompatibilities that can be eliminated by a recoverable group in this transaction, or if the conditions are still not met after full recovery, keep the relevant services stopped and record the reason.

[0087] After determining the set, rollback is performed in reverse order of the original submission. Incomplete verification operations for this group are stopped, and resource status is confirmed. The newly acquired rollback purpose credentials are used to select the original configuration snapshot. The original file summary, the target system service actual loading activity configuration index number, and the original configuration behavior items are checked. Original configuration behavior items are read from the registered original configuration verification list referenced by the baseline. If the conditions for executing original configuration loading and behavior verification are missing, the configuration item will not be included in this online transaction. A rollback record is appended after each group passes; if it fails, a rollback failure record is appended, and related input is stopped. Configuration groups retained outside the set also need to be checked for actual loading and compatibility with remaining combinations. After completion, the transaction failure handling completion record is saved, and the anti-rollback sequence is not advanced. If no group switch occurs, the cancellation result is recorded, the original running status is confirmed, and preparation ends.

[0088] Transaction completion records and transaction failure handling completion records are collectively referred to as transaction termination records. Both records store the final retained indexes and configuration summaries of each domain. The former indicates that the target configuration request was completed, while the latter indicates that a verifiable retention state has been formed after the failure. Resumption of business input and execution of formal uploads, controls, or record cleanup are based on valid transaction termination records and current service readiness results. Transactions still in the rollback failure stage do not have termination results available for opening related businesses; unaffected businesses with independent entry points operate according to their own states. Index records, pending configuration group records, and termination records are all bound to transaction identifiers and cannot be replaced by successful records of other historical transactions.

[0089] The failure condition summary is generated based on past failures. Inputs include the configuration package summary, configuration plan summary, configuration group identifier, expected preceding state summary, failure stage, failure reason code, and corresponding reason fields. A 32-byte summary is generated using a unified encoding. The reason code is assigned by the specific check branch, such as content summary mismatch, invalid credentials, load timeout, or missing fields. The record also saves a list of fields and values ​​related to the reason. Before retrying, historical failures of the same configuration package and group are retrieved, and the conditions dependent on those historical reasons are reread. If the conditions are still true, duplicate commits are suppressed; if the conditions are eliminated, recompilation is allowed. The cause of the current failure, which has not yet occurred, is not pre-inferred. Format or conflict failures are suppressed if the relevant content remains unchanged. Resource busy and runtime timeouts are reassessed after a new release confirmation or a corresponding health check pass record is obtained. Transaction time, temporary filenames, and newly allocated indexes are not included in the failure condition summary, and different summaries do not replace normal admission checks.

[0090] After the smart terminal restarts, it first keeps the affected service entry points closed and reads the pending commit records, actual indexes, and transaction termination records corresponding to the unfinished transactions. If no valid transaction termination record exists, the preparation of groups that have not been switched is canceled, and the configurations of switched groups are restored in reverse order before the start of the transaction, even if a group has previously passed verification, the target state of the unfinished transaction is not retained. The recovery process appends progress to each group, and continues according to the actual index and saved progress after another power outage. If a valid transaction termination record exists, the final configuration is selected according to that record, and any unwritten anti-rollback sequence required by the successful record is completed and written. Evidence of old startup sessions only indicates historical results. After startup, the service instance, configuration loading, and necessary actions are reconfirmed; if a valid record is missing, its content is corrupted, or recovery verification cannot be completed, the relevant services are stopped. Old credentials become invalid due to changes in startup sessions or resource management service instances. Cleanup only targets files that belong to the current transaction and are not referenced by active indexes, rollback records, or unfinished transactions, and does not directly clear inactive configuration slots.

[0091] In one application embodiment, the smart terminal is used for image acquisition, preprocessing, defect analysis, and result recording on the production line, and has a neural network processor resource (NPU0) managed by a resource management service. The original active configuration index number of the video processing atomic submission domain is 17, the analysis processing atomic submission domain is 8, and the recording processing atomic submission domain is 4. These values ​​are read by the system-level configuration service. The candidate configuration package includes 7 configuration state migration units: migration unit 01 modifies the acquisition size, migration unit 02 modifies the clipping and normalization configuration, migration unit 03 modifies the model file and input interface, migration unit 04 modifies the defect category explanation, migration unit 05 modifies the result upload field, migration unit 06 modifies the record retention configuration, and migration unit 07 modifies the runtime audit configuration. The first two units form Group 1, the middle two units form Group 2, and the last three units form Group 3, each belonging to one of the three atomic submission domains mentioned above. Group 2 depends on Group 1, and Group 3 depends on Group 2.

[0092] This example changes the original image size from 1280 pixels by 720 pixels to 1920 pixels by 1080 pixels. The model interface specification stipulates that the cropped input remains 640 pixels by 640 pixels. The new configuration takes pixels from the horizontally and vertically centered areas of the input image; therefore, the cropping start point is 640 pixels from the left and 220 pixels from the top. The new model interface specifies that the input is floating-point data arranged by channel. Preprocessing is done by writing the data sequentially according to the red, green, and blue channels. Each 8-bit unsigned pixel value is divided by 255, where 255 comes from the maximum value of that pixel type. The conversion range is specified by the new model input interface. The old model uses the data representation specified by the original interface. The combination of the old and new interfaces is registered according to S23. The old preprocessing and the old model, and the new preprocessing and the new model can be combined, but cross-combination is not allowed. Verification uses the labeled image and coordinate conditions recorded in S42, and the model recognition result is not inferred based on size changes.

[0093] Assume the available capacities for video processing, analysis processing, and recording processing are 1048576B, 6291456B, and 1048576B respectively. The complete target configuration occupies 262144B, 2621440B, and 262144B respectively. Configuration metadata is reserved at 32768B, 65536B, and 32768B respectively, and verification logs are reserved at 131072B, 262144B, and 131072B respectively. The above capacities represent the file system capacity interface and the read results corresponding to the complete file list in this example. Reserved values ​​are based on the actual recording format and planned verification projects. The requirements for the three domains are 425984B, 2949120B, and 425984B respectively, all not exceeding their respective available capacities. Subtracting the total requirement of 3801088B from the total available capacity of 8388608B leaves 4587520B. This calculation includes a full snapshot and the listed reservations; the model's runtime memory is still checked separately according to S31.

[0094] After all target snapshots are pre-written, related business input is paused. Group 1 obtains the necessary resource authorizations and generates a configuration group record to be submitted. After the pre-checks pass, the active configuration index number of the video processing atomic submission domain is switched from 17 to 18. The target system service loads the acquisition and pre-processing configuration and executes the verification input. After the configuration readback, actual loading, and pre-processing output checks pass, a version loading consistency evidence record is formed for Group 2 to prepare for use. At this time, formal business input has not yet resumed.

[0095] Suppose that the generation of NPU0 was 40 when it was originally occupied by the task, and 41 after actual release. During the stable observation period before credential generation, another task not belonging to the affected business link occupied the resource, changing the generation to 42, and then to 43 after release. The original observation based on generation 41 could no longer be used. After re-checking generation 43 in the 200ms stable observation obtained by S32 calibration, the resource management service generates a credential bound to the current generation in the mutual exclusion operation; during the validity period of the credential, unauthorized task occupancy requests are rejected, and the generation is no longer increased. After the second set of credentials and expected pre-states are valid, the activity configuration index number of the analysis processing atomic commit domain is switched from 8 to 9, and model loading and behavior output are verified. The third set then switches the activity configuration index number of the record processing atomic commit domain from 4 to 5 according to the same preparation and commit rules.

[0096] If Group 2 fails its initial verification and Group 3 has not yet switched over, Group 2 should be included in the rollback scope first. Since the restored old model cannot receive the new preprocessed output of Group 1, Group 1 should also be rolled back, restoring indices 8 and 17 in the order of Group 2 and Group 1. If all three groups have completed group verification, but the final joint check finds that the service instance of Group 2 has changed and the target configuration is not loaded, then Group 3 has already switched over. Group 3 should be included in the scope according to dependencies and compatibility relationships, restoring indices 4, 8, and 17 in the order of Group 3, Group 2, and Group 1. The actual switching status should be saved separately for both cases, and Group 3, which has not yet switched over, should not be written as having been rolled back.

[0097] If all three groups and the final combination pass the checks, the transaction completion record is saved and the rollback prevention sequence is updated, and then relevant business inputs are enabled. If a power outage occurs after the switch and the transaction does not have a valid termination record, the original configuration of the transaction is restored by pressing S43 after restarting, and the old credentials are no longer used. The system returns the configuration package identifier, transaction result, final index set, and version load consistency evidence record summary to the platform configuration management unit; volatile memory stores the run queue, current authorization, and status coordination data, while non-volatile memory stores the program, configuration snapshot, and transaction record, enabling subsequent queries to be linked to the current configuration and recovery results.

[0098] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for managing and controlling intelligent terminals based on dynamic configuration, characterized in that, include: Acquire candidate configuration packages, collect terminal capability baselines, current active configurations and initial running evidence records, form transaction baseline sealing records, and append the state changes after the baseline cutoff number to the incremental running evidence chain; Based on the candidate configuration package, transaction baseline archive records, and incremental execution evidence chain, construct an evidence constraint configuration migration graph, form an atomically visible configuration group within the same atomic commit domain, establish a group-level dependent directed acyclic graph, and generate an executable configuration plan that includes the expected pre-state and dependency compatibility conditions determined at compile time. According to the executable configuration plan, write the complete target configuration snapshot to the inactive configuration slot and read back the pre-check, suspend the affected business input and clean up the tasks in transit, establish a resource release generation barrier for the managed resources involved and obtain exclusive submission credentials, and form a record of the configuration group to be submitted. Based on the configuration group record to be submitted, the pre-state and exclusive submission credentials are verified under mutual exclusion protection. The active configuration index is switched through atomic switching, and a version loading consistency evidence record is generated based on the configuration readback result, the actual loading active configuration index sequence number of the target system service, and the behavior verification result. If it fails, the rollback configuration group set is determined and rolled back based on the group-level dependency directed acyclic graph, index switching status, and dependency compatibility conditions. After all configuration groups and dependency combinations are verified or the rollback verification is passed, the transaction termination record is saved and the affected business input is restored.

2. The method for managing and controlling intelligent terminals based on dynamic configuration according to claim 1, characterized in that, The process of creating the transaction baseline archive record includes: Verify the platform digital signature, configuration list and file digest, applicable terminal conditions, system service version and configuration update sequence of the candidate configuration package, and extract the configuration status migration unit and its relationship record with unique identifier, read configuration item, modified configuration item, original configuration conditions and target configuration value; The terminal capability baseline is formed by collecting terminal device interface, atomic submission domain registration form, configuration structure and configuration slot capacity; the current active configuration is formed by reading the configuration item value, configuration list and immutable file location corresponding to the active configuration index; and the initial running evidence record is formed by collecting running task, resource usage, resource generation count, startup session and service instance information. After the relevant state event subscription is established, the state snapshot and baseline cutoff number are obtained through the state coordination lock. The terminal capability baseline, current activity configuration and initial running evidence record are associated with the current transaction identifier, configuration package summary and baseline cutoff number and persisted to form the transaction baseline archive record. Subsequent events generated during the baseline record persistence period are retained.

3. The method for managing and controlling intelligent terminals based on dynamic configuration according to claim 2, characterized in that, Generating and using the incremental running evidence chain includes: Changes in resource usage, resource generation count, running tasks, target system service status, and activity configuration index after the baseline cutoff number are formed into evidence events, and the object identifier, state before change, state after change, state collection time and source, and instance identifier are saved. Add evidence events according to the event sequence number. The first evidence event is associated with the transaction baseline archive record summary. Subsequent evidence events are associated with the previous evidence event summary. When restoring the state, check the state before the change and the current restored state item by item. If they are consistent, apply the state after the change. The freshness of runtime evidence is checked based on the state collection time within the same startup session. For states that exceed the freshness threshold of runtime evidence, they are re-collected and state confirmation events are added. The chain prefix used for this compilation is fixed with the compilation deadline event number and summary. The corresponding plan is stopped when the event is missing, the summary is inconsistent, or the source instance changes.

4. The method for managing and controlling intelligent terminals based on dynamic configuration according to claim 1, characterized in that, Forming the atomic visible configuration group includes: Based on the terminal capability baseline and compile-time runtime status, check the static admission conditions and dynamic execution conditions of the configuration state transition unit, record the resource occupancy status that can be released in a controlled manner as the execution waiting condition, and stop the current transaction when the necessary migration object does not meet the admission conditions. Check if dependent objects and co-effective objects are complete, and check for declared conflict relationships and whether the same configuration item is specified with different target values. If there are missing objects or configuration conflicts, stop the current transaction and execute the remaining configuration without deleting the necessary configuration state migration units. A set to be merged is formed based on mutually reachable dependencies and common effective relationships. When the set spans different atomic commit domains, the current transaction is stopped. When the set is in the same atomic commit domain, the configuration state migration units of the current transaction within that atomic commit domain are merged into an atomically visible configuration group.

5. The method for managing and controlling intelligent terminals based on dynamic configuration according to claim 4, characterized in that, Generating the executable configuration plan includes: A group-level dependency graph is formed with atomically visible configuration groups as nodes and cross-group dependencies as directed edges. The commit order is determined by selecting configuration groups that do not have unprocessed predecessors in sequence. If there is a dependency cycle that cannot determine the commit order, the current transaction is stopped. Based on the compile-time configuration status and the target output of the predecessor group of this transaction, determine the expected prerequisite status of each group, and determine the dependency compatibility conditions based on the producer output interface and consumer input interface, and record the complete target configuration list, resource list, execution wait conditions, verification items and rollback rules; The configuration plan summary is generated by using group members, commit order, expected pre-state, dependency compatibility conditions, target configuration and verification content as plan content fields. The transaction identifier, transaction baseline archive record summary, compilation deadline event information, configuration slot position and source and target active configuration index sequence number are saved and verified as execution binding fields to form the executable configuration plan.

6. The intelligent terminal management and control method based on dynamic configuration according to claim 1, characterized in that, Write the complete target configuration snapshot to the inactive configuration slot and read back the pre-check, including: According to the executable configuration plan, the update retention of the relevant configuration domains is obtained. The unmodified configuration is retained in the original configuration list and the addition, modification and deletion operations in the candidate configuration package are applied to form a complete target configuration list. The space required for the complete target configuration, configuration metadata and verification logs are checked and reserved respectively. Write the complete target configuration to a temporary file in the inactive configuration slot, and then perform file synchronization, atomic renaming and directory synchronization in sequence. At the same time, retain the original configuration snapshot and save the verification log in the transaction record area. Reread the complete target configuration, check the path, length and digest of each file, generate a configuration readback digest and compare it with the expected digest corresponding to the complete target configuration list. If the comparison is successful, record the write-ahead check pass status.

7. The method for managing and controlling intelligent terminals based on dynamic configuration according to claim 1, characterized in that, Obtaining the exclusive submission credential and forming the pending configuration group record includes: When managed resources are effectively occupied, effectively released, or the device that causes the existing state to become invalid is reset, the resource generation count is updated. After the affected business input is suspended and the relevant tasks, device queues, and access references are cleaned up, a release stability check is performed to form the resource release generation barrier. In the mutual exclusion operation of the resource management service, the resource status, resource generation count and retention status are re-examined. If they pass, an exclusive retention is established, and an exclusive commit credential is generated that binds the resource identifier, resource generation count, start session identifier, resource management service instance identifier, current transaction identifier and configuration group identifier. The exclusive retention is maintained during the corresponding configuration loading and behavior verification. Generate an expected prerequisite state summary based on the fixed expected prerequisite states in the executable configuration plan. Persist the summary, configuration plan summary, configuration readback summary, execution binding field, exclusive commit credential identifier, and original configuration snapshot location to form the configuration group record to be committed. The records of the successor group are also associated with the valid version loading consistency evidence record of the predecessor group on which they depend.

8. The method for managing and controlling intelligent terminals based on dynamic configuration according to claim 1, characterized in that, Generate the version load consistency evidence record and perform a rollback, including: During the same mutual exclusion protection process, the source activity configuration index sequence number, current pre-state summary, configuration plan summary, execution binding field and exclusive commit credentials are checked. The activity configuration index is then updated through post-persistence updates, so that the target system service consistently reads the configuration snapshot corresponding to that index. After the target system service completes configuration parsing and establishes an active running object for processing verification input, it obtains the actual loading information bound to the running object, and generates a version loading consistency evidence record by combining the configuration readback result and the behavior result of the corresponding verification request. Upon failure, the switched failure group and the switched configuration group that depends on its output are added to the rollback configuration group set. The set is expanded according to the dependency compatibility conditions of the restored version combination. The original configuration is restored in reverse commit order, and the files, actual loading, and behavior results are verified. At the same time, a failure condition summary is generated based on the failure reasons and their dependency fields for subsequent duplicate commit judgment.

9. A smart terminal management and control system based on dynamic configuration, characterized in that, It includes a platform configuration management unit, a terminal management client, a runtime evidence collection unit, a configuration compilation unit, an inactive configuration slot pre-inspection unit, a resource generation management unit, a configuration submission unit, a version loading consistency verification unit, and a configuration rollback unit; The platform configuration management unit is used to generate and send candidate configuration packages, the terminal management client is used to verify candidate configuration packages and control the configuration transaction status, and the running evidence collection unit is used to collect terminal capability baseline, current active configuration and initial running evidence records to form transaction baseline sealing records and incremental running evidence chains. The configuration compilation unit is used to check the configuration state transition unit and its relationship based on the candidate configuration package, transaction baseline archive record and incremental running evidence chain, form atomic visible configuration group and group-level dependency directed acyclic graph, and generate an executable configuration plan containing expected pre-state and dependency compatibility conditions. The inactive configuration slot pre-check unit is used to form a complete target configuration snapshot and complete write and readback pre-checks. The resource generation management unit is used to update the resource generation count, check resource release conditions, and obtain exclusive submission credentials. The configuration submission unit is used to control the affected business input, form a record of configuration groups to be submitted, and switch the active configuration index under mutual exclusion protection. The version loading consistency verification unit is used to verify the configuration content, actual loading information, and behavior verification results. The configuration rollback unit is used to determine the rollback configuration group set and perform rollback verification based on dependencies, index switching status, and dependency compatibility conditions.

10. A smart terminal management and control system based on dynamic configuration according to claim 9, characterized in that, It also includes a terminal-side processor, volatile memory, non-volatile memory, active configuration slots, inactive configuration slots, system-level configuration services, resource management services, and target system services; The non-volatile memory is used to store programs, configuration snapshots, transaction baseline archive records, incremental execution evidence chains, executable configuration plans, pending configuration group records, active configuration indexes, version loading consistency evidence records, and transaction termination records. The system-level configuration service is used to manage configuration update retention and persistent index switching. The resource management service is used to maintain resource status and exclusive retention. The target system service is used to load configuration snapshots and return the actual loading information bound to the active running object. The terminal-side processor is used to execute the program to implement the method described in any one of claims 1 to 8, and after restarting, it first processes unfinished transactions based on the actual index, the configuration group record to be submitted, and the transaction termination record, then obtains the target system service loading confirmation in this startup, completes and writes the anti-rollback sequence required for the valid transaction completion record, and keeps the input paused for related services that cannot determine the valid configuration or cannot complete the recovery verification.

Images