A weak network offline closed-loop management method and system for a construction labor self-service integrated machine

Abstract

This invention relates to the field of smart construction site labor management technology, and discloses a method and system for closed-loop management of self-service construction site labor machines in weak network conditions. The method includes: acquiring network status parameters and determining the current network level; verifying the identity of laborers, generating business events and associated local evidence packages; writing both into a local persistent event queue, and determining processing permissions based on network level and business risk level; reading events to be synchronized when the network recovers, and performing compensatory synchronization according to business type; performing conflict resolution and state convergence based on event and evidence fields; and performing state propagation updates for subsequent events when the state of a preceding business event changes. This invention can ensure continuous processing of labor services in weak network or offline environments, and achieve differentiated synchronization, conflict verification, and state convergence after network reconnection.

Description

Technical Field

[0001] This invention relates to the field of smart construction site labor management technology, and more specifically, to a method and system for closed-loop management of a self-service construction site labor self-service machine in the event of a weak network connection. Background Technology

[0002] On construction sites, labor management typically involves multiple steps, including identity verification, attendance tracking, labor contract signing, wage confirmation, training and examinations, and departure settlement. While existing self-service labor management equipment on construction sites can handle these tasks to some extent, the following problems still exist in its actual application on construction sites.

[0003] First, the network environment at construction sites is complex, with weak or out-of-network scenarios in areas such as basements, core tubes, steel structure enclosures, and temporary facilities. Existing systems mostly rely on the cloud for business confirmation, data writing, and status updates. Once a network anomaly occurs, they often can only be processed at the level of "local temporary storage and subsequent upload," making it difficult to guarantee continuous business processing and consistent results.

[0004] Secondly, construction sites have a large number of workers with high mobility and varying levels of digital operational skills. Existing systems typically present functions such as attendance, contracts, wages, and settlements in a fragmented manner, requiring workers to switch repeatedly between multiple business pages and confirm repeatedly. This easily leads to errors, omissions, duplicate submissions, and proxy operations, disrupting the on-site management chain, distorting information, and making it difficult to provide convincing and complete evidence in the event of future labor disputes.

[0005] Third, existing offline capabilities are typically only geared towards a single business or simple caching, lacking a unified mechanism for handling semantic differences between different businesses. For example, attendance management focuses on high-frequency deduplication, contract management focuses on document version consistency, payroll management focuses on batch consistency, and departure settlement management focuses on dependencies of preceding businesses. Most existing solutions do not design differentiated compensation and synchronization rules for different businesses, which can easily lead to duplicate records, version conflicts, batch overwriting, and state mismatches after network connectivity is restored.

[0006] Fourth, in existing solutions, data generated offline is typically only cached, lacking an evidence association mechanism corresponding to business events. This makes it difficult to verify and converge data during subsequent synchronization based on technical fields such as event number, document version, terminal identifier, timestamp, and preceding event relationships. Consequently, while the system can "record," it struggles to achieve "reliability, traceability, and convergence."

[0007] Therefore, a closed-loop management solution for weak network offline scenarios is needed for self-service labor kiosks on construction sites. This solution can enable critical business operations to continue even in weak network or outage environments, and complete differentiated synchronization, conflict resolution, and state convergence based on business events and evidence packages after network recovery, thereby forming a true closed loop for construction site labor management. Summary of the Invention

[0008] To address the shortcomings of existing technologies, the purpose of this application is to provide a method and system for closed-loop management of weak network offline operations for self-service labor terminals at construction sites.

[0009] To achieve the above objectives, this application provides the following technical solution:

[0010] A closed-loop management method for offline operations of self-service labor service machines on construction sites under weak network conditions includes the following steps:

[0011] S1, obtain the network status parameters of the self-service labor terminal at the construction site, and determine the current network level based on the network status parameters;

[0012] S2, based on the business processing request, verifies the identity of the personnel, and generates the corresponding business event and the local evidence package associated with the business event according to the business type, current network level, business risk level and the status of the preceding business event;

[0013] S3 writes the business event and local evidence package into the local persistent event queue, and determines the processing authority of the business event based on the current network level and business risk level.

[0014] S4, when network recovery is detected, read the business events to be synchronized and their corresponding local evidence packages in the local persistent event queue, call the corresponding compensation synchronization rules according to the business type, and synchronize the business events to be synchronized and their corresponding local evidence packages to the cloud platform.

[0015] S5, during the synchronization process, based on the document version identifier, preceding event identifier, and current synchronization status in the business event, as well as the terminal identifier, device timestamp, and current business processing result summary in the local evidence package, performs duplicate verification, version consistency verification, preceding dependency order verification, and upstream and downstream state consistency verification on the business event to be synchronized, and performs conflict resolution and state convergence on the business event according to the verification results.

[0016] S6, when a preceding business event enters a pending review state, the subsequent business events associated with the preceding business event are set to an associated pending review state; when the preceding business event is restored to a valid state, the corresponding unlock update is performed on the subsequent business events; when the preceding business event is determined to be in an invalid state, the corresponding invalidation update is performed on the subsequent business events.

[0017] In a preferred embodiment, in step S1, the network status parameters include at least the link communication success rate, response latency, network interface availability status, and number of consecutive communication failures.

[0018] The current network level includes at least online processing status, weak network restricted processing status, and offline local processing status.

[0019] In a preferred embodiment, in step S2, when processing online, the identity of the worker is verified by combining ID card information with live facial recognition.

[0020] In the case of processing under weak network conditions and offline local processing conditions, offline temporary identity verification results are generated by matching ID card information with the local identity index database.

[0021] After identity verification is successful, a trusted session is established, and the interactive components are controlled to switch to the next business processing page based on the pending tasks, the status of previous business events, and the business risk level.

[0022] In a preferred embodiment, in steps S2 and S3, the business event includes at least the event number, business type identifier, personnel identifier, project identifier, terminal identifier, event time, document version identifier, current business status, current synchronization status, risk level, preceding event identifier, and trusted session identifier;

[0023] The local evidence package includes at least one of the following: identity verification result summary, liveness detection result summary, ID card information summary, face capture summary, signature image summary, fingerprint image summary, business document version identifier, device timestamp, terminal identifier, previous event summary, and current business processing result summary.

[0024] In a preferred embodiment, step S3, determining the processing authority for a business event includes: outputting a local closed-loop result for low-risk business; outputting a temporarily valid result for medium-risk business; and initially limiting high-risk business to pending confirmation processing, and updating it to temporarily valid pending review processing when preset review conditions are met.

[0025] In a preferred embodiment, step S4 involves invoking the corresponding compensation synchronization rules according to the business type, including: for attendance-related businesses, using the project identifier, personnel identifier, and identification time window as the deduplication primary key; for contract signing-related businesses, using the contract number and document version identifier as the consistency verification primary key; for payroll confirmation-related businesses, using the payslip number, personnel identifier, and confirmation batch as the primary key; for training and examination-related businesses, using the test paper version, personnel identifier, and submission sequence number as the primary key; and for departure settlement-related businesses, using the settlement slip number, personnel identifier, and signing date as the primary key.

[0026] In a preferred embodiment, in step S4, the business event to be synchronized corresponds to at least the enqueue time, retry count, most recent synchronization result, next retry time, priority identifier, review identifier, and subsequent dependent business identifier; the business events to be synchronized are read from the local persistent event queue in descending order of priority.

[0027] After conflict resolution and state convergence are performed in steps S5 and S6, the status of the business events to be synchronized will be updated to final valid, pending review, associated pending review, or invalid.

[0028] A closed-loop management system for a construction site self-service labor terminal under weak network conditions includes a construction site self-service labor terminal and a cloud platform, wherein:

[0029] The self-service terminal for construction site workers includes a processor, memory, display and interaction components, ID card reading components, image acquisition components, and communication components, and also includes:

[0030] The network status determination module is used to acquire network status parameters and determine the current network level based on the network status parameters.

[0031] The identity verification module is used to verify the identity of workers.

[0032] The business event generation module is used to generate corresponding business events based on the business type, current network level, business risk level, and the status of preceding business events.

[0033] The local evidence package generation module is used to generate local evidence packages associated with business events;

[0034] The local persistent event queue module is used to write business events and local evidence packages into the local persistent event queue, and determine the processing authority of business events based on the current network level and business risk level.

[0035] The differentiated compensation synchronization module is used to read the business events to be synchronized and the corresponding local evidence packages from the local persistent event queue when network recovery is detected, and to call the corresponding compensation synchronization rules according to the business type to synchronize the business events to be synchronized and the corresponding local evidence packages to the cloud platform.

[0036] The conflict resolution and state convergence module is used during the synchronization process to perform duplicate checks, version consistency checks, predecessor dependency order checks, and upstream and downstream state consistency checks on the business events to be synchronized, based on the document version identifier, predecessor event identifier, and current synchronization state in the business events, as well as the terminal identifier, device timestamp, and current business processing result summary in the local evidence package. Based on the check results, it performs conflict resolution and state convergence on the business events. Specifically, when a predecessor business event enters a pending review state, the conflict resolution and state convergence module also sets subsequent business events associated with the predecessor business event to an associated pending review state; when a predecessor business event is restored to a valid state, it performs corresponding unlock updates on subsequent business events; and when a predecessor business event is determined to be invalid, it performs corresponding invalid updates on subsequent business events.

[0037] The cloud platform is used to receive business events and local evidence packages synchronized from the self-service labor terminal at the construction site, and to perform status verification, review and archiving based on the received data.

[0038] In a preferred embodiment, the self-service terminal for construction site labor services further includes a trusted session and page switching control module, a local identity index, and a local database, wherein:

[0039] The trusted session and page switching control module is used to establish a trusted session after identity verification is passed, and to control the switching of the display interaction components to the next business processing page according to the pending tasks, the status of previous business events and the business risk level.

[0040] The local identity index store de-identified hash digest identity index data, along with a version identifier, to facilitate version updates with the cloud platform;

[0041] The local database includes at least an event queue storage area and an evidence package storage area.

[0042] In a preferred embodiment, the system also includes an on-site data collection terminal, which is used to cross-check the identity verification results, personnel identification, event time, and terminal identification based on the data collection results sent by the on-site data collection terminal, and to determine whether the business processing personnel are consistent with the on-site personnel and whether the business processing time is consistent with the on-site data collection time based on the cross-checking results.

[0043] The self-service terminal for construction site labor services serves as the main body for unified deduplication, unified version verification, and unified status convergence.

[0044] By adopting the above technical solution, the beneficial effects of this invention are as follows: First, through network status determination, local persistent event queues, and local evidence package mechanisms, even in weak or offline network environments, business processes such as identity verification, attendance recording, new employee registration, contract signing, salary confirmation, training and examination, and departure settlement can continue to proceed on the terminal side without relying on a continuous online cloud connection. Second, by uniformly abstracting different business processes into business events and solidifying information such as terminal identifiers, device timestamps, document version identifiers, preceding event identifiers, and business processing result summaries into local evidence packages, subsequent synchronization is not merely "data upload," but can perform version verification, dependency verification, and state convergence based on events and evidence, improving the reliability and traceability of the results. Third, by setting different synchronization primary keys and criteria for the five types of business processes—attendance, contract signing, salary confirmation, training and examination, and departure settlement—the problems of duplicate records, version conflicts, batch overwriting, and timing errors caused by unified retransmission after network recovery are reduced. Fourth, through the preceding business event state propagation mechanism, business processes with dependencies, such as contracts, salaries, and settlements, can form a true on-site closed loop, rather than a loose stacking of functions. Attached Figure Description

[0045] Figure 1 This is a schematic diagram of a closed-loop management method for weak network offline of a self-service labor terminal at a construction site, according to the first embodiment of this application.

[0046] Figure 2 This is a schematic diagram of the architecture of a weak network offline closed-loop management system for a self-service construction site labor terminal according to the second embodiment of this application. Detailed Implementation

[0047] In the following description, many technical details are presented to help the reader better understand this application. However, those skilled in the art will understand that the technical solutions claimed in this application can be implemented even without these technical details and various variations and modifications based on the following embodiments.

[0048] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0049] It should be noted that, in this application, "business event" refers to a data object formed around a single business processing action, used to carry information such as business type, personnel identifier, project identifier, terminal identifier, document version identifier, current business status, current synchronization status, risk level, preceding event identifier, and trusted session identifier; "local evidence package" refers to a set of evidence data generated corresponding to a business event, used to carry information such as identity verification result summary, liveness detection result summary, signature image summary, device timestamp, terminal identifier, and current business processing result summary; "preceding business event" refers to a business event that is confirmed or reviewed before the current business event in business logic; "subsequent business event" refers to a business event that depends on the status of the preceding business event.

[0050] The "weak network offline closed loop" in this application refers to the following: In a weak network or network outage environment, the terminal can still generate business events and local evidence packages for business such as identity verification, attendance, contract signing, salary confirmation, training and examination, and departure settlement; after the network is restored, differentiated compensation synchronization, conflict resolution and state propagation are performed based on the business event field and the local evidence package field, thereby outputting verifiable and traceable business processing results.

[0051] The first embodiment of this application provides a closed-loop management method for weak network offline operations of a self-service labor terminal at a construction site. The method flow is as follows: Figure 1 As shown, the method includes the following steps S1 to S6:

[0052] S1: Obtain network status parameters and determine the current network level;

[0053] S2: Verify the identity of the workers and establish a trusted session;

[0054] S3: Generate business events and local evidence packets based on business type, current network level, business risk level, and the status of preceding business events;

[0055] S4: Write the business event and local evidence package into the local persistent event queue, and determine the processing authority based on the current network level and business risk level;

[0056] S5: When the network recovers, read the business events to be synchronized and the corresponding evidence packets, perform differentiated compensation synchronization according to the business type, and perform conflict resolution and state convergence.

[0057] S6: When the state of a preceding business event changes, the execution state of subsequent business events is propagated and updated.

[0058] The following sections will explain S1 to S6 respectively.

[0059] S1: Obtain network status parameters and determine the current network level

[0060] In this step, the self-service terminal for construction site labor services obtains network status parameters, which include at least: link communication success rate, response latency, network interface availability status, and number of consecutive communication failures.

[0061] In one implementation, network testing can be performed periodically via a terminal program. Specifically, it first checks whether the local network interface is available, and then accesses a preset public IP address or cloud service address to obtain the communication success rate and average response latency. In another implementation, network connectivity testing can be performed using Java's java.net package, and the network status can be returned based on the test results.

[0062] To ensure a consistent evaluation of link quality, the following network quality scoring model is adopted in this embodiment:

[0063]

[0064] in: Rate the network quality; For link communication success rate; This represents the average response time. This is the maximum allowable delay threshold; This indicates the availability status of the network interface; a value of 1 indicates the interface is available, and a value of 0 indicates it is unavailable. This represents the number of consecutive communication failures. This is the threshold for the maximum allowed number of failures; , , , Let be the weighting coefficient, satisfying

[0065] In a preferred embodiment, it is advisable to and set a first threshold. Second threshold when When the time is right, it is determined to be in the online processing status; when At that time, it was determined to be a weak network restricted processing status; when At that time, it was determined to be in an offline local processing status.

[0066] To mitigate the impact of device clock drift on attendance time window deduplication and timing judgment in a weak network environment at the construction site, this embodiment performs clock calibration every time a valid connection is established with the cloud platform. Specifically, the terminal obtains the cloud server's timestamp through the HTTPS response header or the cloud time interface. Read local clock time And calculate the clock offset:

[0067]

[0068] Then offset Cache the data in the local configuration area and perform compensation when generating device timestamps later:

[0069]

[0070] In a preferred embodiment, if three consecutive calibration results satisfy If the clock fails to complete within a minute, a device clock anomaly alarm will be triggered, and the final confirmation of high-risk services will be suspended, allowing them to enter a pending confirmation or temporary valid pending review status only.

[0071] Therefore, network status determination not only determines the three processing paths of online, weak network, and offline, but is also directly related to subsequent timing judgments, deduplication windows, and high-risk business synchronization conditions, thereby improving the stability and consistency of subsequent business event processing.

[0072] S2: Identity verification and establishment of a trusted session

[0073] In this step, the terminal responds to the service personnel's business processing request and performs identity verification on the service personnel.

[0074] In online processing, the terminal reads the ID card information using the ID card reader component, and simultaneously captures a facial image of the person on-site using the image acquisition component and performs liveness detection. The captured facial features are then compared with facial features stored in the cloud. In a preferred embodiment, when the similarity score reaches or exceeds 90 points, the person is identified as the same individual and verification is successful.

[0075] In situations where processing is restricted due to weak network conditions or offline local processing, the terminal generates an offline temporary identity verification result by matching ID card information with a local identity index database. In this embodiment, the local identity index database is constructed based on a pre-set local personnel information table.

[0076] Specifically, the local personnel information table stores the basic identity information, job information, on-duty status information, and synchronization status information of registered personnel to support offline ID card matching, personnel status determination, and local identity index database updates. In one implementation, the local personnel information table includes at least the following fields: id, lessee_id, catalog_id, name, identity_card, group_id, group_name, work_type_id, work_type_name, enter_date, exit_date, job_status, live_tag, contrast_tag, register_type, identification_photo, scene_photo, sync_id, created_time, and modified_time.

[0077] The `identity_card` field is used for offline ID card number matching; the `job_status` field is used to determine whether a person is currently employed; the `live_tag` and `contrast_tag` fields are used to record the results of liveness detection and identity verification; and the `sync_id` field is used to identify the synchronization sequence number or version of the person's data, so that differential updates to the local identity index can be performed when the network recovers. Therefore, it is reasonable to keep `sync_id` in the local personnel information table, as it not only serves the background synchronization but also directly supports the consistency maintenance between the local and cloud databases.

[0078] In one specific implementation, in offline mode, the ID card number is obtained through an ID card reader and matched against the `identity_card` field in the local personnel information table. If a match is found, login is allowed. This ensures uninterrupted identity authentication even when the network is offline.

[0079] After identity verification is successful, the terminal establishes a trusted session. A trusted session is associated with at least the personnel identifier, session start time, and the identifier of the current pending task chain. Further, the terminal controls the display interaction components to switch to the next service page based on the pending task, the status of preceding business events, and the business risk level.

[0080] For example, when the contract signing process is not yet completed, the user is directed to the contract signing page first; once the contract signing event reaches the "can continue" state, the user is switched to the pay confirmation page; and once the pay confirmation is completed, the user is switched to the departure settlement page.

[0081] Thus, identity verification, trusted sessions, and page switching control form the front-end entry point of a continuous processing chain, so that the generation of subsequent business events is no longer triggered by independent menus, but is constrained by both identity status and previous status.

[0082] S3: Generate business events and local evidence packages

[0083] In this step, the terminal generates a service event based on the service type, current network level, service risk level, and the status of preceding service events, and simultaneously generates a local evidence packet associated with the service event.

[0084] A business event must include at least the following: event number, business type identifier, personnel identifier, project identifier, terminal identifier, event time, document version identifier, current business status, current synchronization status, risk level, preceding event identifier, and trusted session identifier. A local evidence package must include at least one of the following: identity verification result summary, liveness detection result summary, ID card information summary, face capture summary, signature image summary, fingerprint image summary, business document version identifier, device timestamp, terminal identifier, preceding event summary, and current business processing result summary.

[0085] In one specific implementation, different business processes use different fields to construct business events and local evidence packages.

[0086] For attendance management, the following fields can be used in the attendance table: catalogId, peopleId, identifyTime, deviceKey, deviceName, model, identifyType, recType, passType, area, and base64.

[0087] For contract signing, the following fields from the contract table can be used: people_id, contract_template_id, contract_template_name, contract_number, status, contract_file, contract_backup_photo_url, and modified_time.

[0088] For payroll confirmation, the following fields can be used from the payroll table: salary_id, people_id, salary_verify_type, salary_verify_standard, final_salary_verify_standard, attendance_count, final_price, verify_tag, signature_url, fingerprint_url, and face_swiping_url.

[0089] For training and examination operations, the fields train_id, people_id, people_score, qualified_tag, created_time, and modified_time from the training table can be used;

[0090] For departure settlement transactions, the fields people_id, identity_card, pending_salary, deadline, signature_url, signature_date, attachment, backup_photo_url, and modified_time in the settlement table can be used.

[0091] To facilitate the assessment of the completeness of evidence for high-risk transactions in offline scenarios, the following evidence completeness model is adopted in this embodiment:

[0092]

[0093] in: Score the completeness of the evidence; Indicates the first If an evidence item exists and satisfies the preset quality condition, the value is 1 if it does, and 0 otherwise. For the weight of the corresponding evidence item, satisfying .

[0094] In a preferred embodiment, an evidence completeness threshold is set for high-risk transactions such as contract signing, payroll confirmation, and exit settlement. .when When this occurs, the service is allowed to enter a temporary, valid pending review status; when At that time, it only enters the pending confirmation state.

[0095] To enhance the tamper-proof capability of local evidence packets, this embodiment generates a current digest value for each local evidence packet. And record the summary value of the previous evidence package. This forms a digest chain. Specifically, the current digest value can be generated as follows:

[0096]

[0097] in: Indicates the first A set of key fields for each business event; This represents the set of key fields in the local evidence package corresponding to this business event; This represents the summary value of the previous evidence package; This represents a hash operation. The digest value can be stored in the evidence package for use in subsequent synchronization to verify the integrity of the evidence chain.

[0098] Furthermore, since local evidence packages are generated and bound to business events in a unified manner, different businesses can enter the local queue in the same data object form, and subsequent synchronization is processed according to different rules based on business type, thus forming a collaborative effect of "unified modeling and differential synchronization". This effect cannot be obtained simply by adding a field or a queue.

[0099] S4: Write to the local persistent event queue and determine processing permissions.

[0100] In this step, the terminal writes the business event and local evidence packet into the local persistent event queue, and determines the processing authority based on the current network level and business risk level.

[0101] In one implementation, the terminal writes business events to the event queue storage area of ​​the local database and writes local evidence packages to the evidence package storage area through the same transaction, so as to reduce the risk of event and evidence separation in the event of power failure or abnormal exit.

[0102] Each business event to be synchronized in the local persistent event queue corresponds to at least: enqueue time, number of retries, most recent synchronization result, next retry time, priority identifier, review identifier, and subsequent dependent business identifier.

[0103] In one implementation, in addition to local database storage, business data is also written to the MQ delayed queue; when consuming data from the delayed queue, incremental storage is performed through a preset callback address; when it is detected that the network has not yet recovered, the data is put back into the MQ delayed queue to continue waiting for retry; when the network has not recovered after more than 24 hours, a manual inspection of the device network is triggered.

[0104] Regarding the determination of processing authority: for low-risk business, local closed-loop processing is allowed; for medium-risk business, temporary valid results are allowed; for high-risk business, it is initially limited to processing pending confirmation, and then updated to temporary valid processing pending review when the preset review conditions are met.

[0105] In this embodiment, business risk levels are linked to underlying storage and synchronization strategies. Specifically: for low-risk businesses, ordinary encrypted tablespace storage is used, and a lower synchronization priority is assigned; for medium-risk businesses, field-level anonymized storage is used, and a medium synchronization priority is assigned; for high-risk businesses, encrypted storage after integrity verification is used, and a high synchronization priority is assigned, while formal synchronization is only performed after the network level meets preset conditions. Therefore, risk level is no longer merely a page control condition, but participates in the selection of underlying storage, verification, and synchronization paths.

[0106] S5: Read the business events to be synchronized and perform differential compensation synchronization, conflict resolution, and state convergence.

[0107] In this step, once network recovery is detected, the terminal reads the business events to be synchronized and the corresponding local evidence packets from the local persistent event queue, and processes them in descending order of business event priority.

[0108] In a preferred embodiment, the following priority model is adopted:

[0109]

[0110] in, Rate the priority; Risk level value; Score the completeness of the evidence; For the duration of waiting for synchronization; Maximum normalization wait time; This is a normalized value representing the number of subsequent dependent services. , , , These are the weighting coefficients.

[0111] The system invokes different compensation synchronization rules based on the business type:

[0112] For attendance-related tasks, the project identifier, personnel identifier, and identification time window are used as the primary keys for deduplication. In a specific implementation, the catalogId, peopleId, and identifyTime can also be used to determine whether the data already exists in the cloud. If it does, the data is modified.

[0113] For contract signing transactions, the contract number and document version identifier are used as the primary keys for consistency verification.

[0114] For payroll confirmation transactions, the payslip number, employee ID, and confirmation batch are used as the primary keys.

[0115] For training and examination-related businesses, the test paper version, personnel identification, and submission number are used as primary keys.

[0116] For off-site settlement transactions, the settlement order number, personnel identification, and signing date are used as the primary keys.

[0117] During the synchronization process, the system performs duplicate verification, version consistency verification, predecessor dependency order verification, and upstream and downstream state consistency verification on the business events to be synchronized based on the document version identifier, predecessor event identifier, and current synchronization status in the business events, as well as the terminal identifier, device timestamp, and current business processing result summary in the local evidence package.

[0118] In this embodiment, conflict resolution specifically includes the following three sub-processes:

[0119] (1) Base version determination: When multiple versions of the same service event are detected, the device timestamp, current synchronization status and terminal priority identifier of each version are compared, and the version with the most recent device timestamp and the highest terminal priority is selected as the base version.

[0120] (2) Handling of difference fields: For fields that are inconsistent with the base version, if the field is an accumulative type, the values ​​are merged; if the field is a status enumeration type, the base version value is retained and the non-base version value is written to the conflict log; if the field is a document version identifier or a preceding event identifier, the pending review process is triggered first, instead of being directly overwritten.

[0121] (3) Rollback mark generation: For conflicting fields that cannot be automatically merged, a rollback mark is generated. The rollback mark includes at least the conflicting field name, conflicting field value, terminal identifier and device timestamp. The rollback mark is uploaded to the cloud platform along with the synchronization result for manual review.

[0122] To standardize the quantification of conflict levels, the following conflict scoring model is further adopted in this embodiment:

[0123]

[0124] in: Rate the conflict; For repeating factors; This is a document version inconsistency factor. It is a pre-dependency order anomaly factor; This is a factor indicating inconsistency between upstream and downstream states. Score the completeness of the evidence; to These are the weighting coefficients.

[0125] In a preferred embodiment, a first conflict threshold is set. Second conflict threshold ,and .when When, update to the final valid state; when When, update to "pending review" status; when When an event is not processed, it is updated to an invalid or obsolete status; business events that are subsequently confirmed to no longer require processing are updated to an archived status.

[0126] In this embodiment, because the three processing steps of differentiated compensation synchronization rules, evidence integrity evaluation, priority scheduling, and conflict resolution are executed in a coordinated manner, the system can not only "upload offline data" but also perform convergence processing on multi-service data with business semantic differences after network connection is restored. This reduces the probability of incorrect confirmation caused by multi-terminal concurrency, version changes, and misaligned prior dependencies. This effect cannot be naturally obtained by simply concatenating existing synchronization queues, known version verification, and ordinary caches.

[0127] S6: Propagation of state of preceding business events and updating of subsequent business events

[0128] In this step, the terminal updates the status of subsequent service events based on changes in the status of preceding service events.

[0129] In one scenario, contract signing, payroll confirmation, and exit settlement constitute a continuous business chain.

[0130] When a contract signing transaction enters the pending review stage, the associated payroll confirmation transaction is updated to the associated pending review stage.

[0131] When a payroll confirmation transaction enters a pending review status, the associated departure settlement transaction is updated to an associated pending review status.

[0132] When a preceding business event is restored to a valid state, the system performs the corresponding unlock update for subsequent business events; when a preceding business event is determined to be invalid, the system performs the corresponding invalidation update for subsequent business events.

[0133] In a preferred embodiment, the results of the associated state propagation can also be used in reverse to update the evidence completeness score. That is, if the auxiliary verification results provided by the on-site collection terminal show that the personnel handling the case are inconsistent with the on-site personnel, the evidence completeness score E is reduced, thereby increasing the probability of entering the pending review state during subsequent synchronization. Thus, the on-site collection results are not only used for auxiliary verification, but also participate in the scoring and judgment link before state propagation.

[0134] Through S1 to S6 described above, this embodiment provides a complete implementation path for network state identification, identity verification, business event and evidence packet generation, local persistent queue writing, risk level binding strategy, recovery synchronization, conflict resolution, and state propagation. Specifically, network level determination provides a prerequisite for offline processing, business events and local evidence packets provide data objects for subsequent synchronization, differentiated compensation synchronization and conflict resolution provide a basis for multi-service consistency processing, and preceding event state propagation ensures that the continuous business chain is not interrupted.

[0135] The second embodiment of this application relates to a closed-loop management system for a construction site self-service machine with weak network conditions. The system includes a construction site self-service machine terminal and a cloud platform, and preferably also includes a field data acquisition terminal.

[0136] The self-service terminal for construction site labor is used for on-site identity verification, business event generation, local evidence package generation, local persistent event queue management, differentiated compensation synchronization, and state convergence.

[0137] The cloud platform is used to receive synchronized business events and local evidence packages, and to perform unified status verification, review and archiving;

[0138] The on-site data acquisition terminal is used to collect global image information and auxiliary identity verification information on-site, and to provide cross-verification data to the self-service labor terminal on the construction site.

[0139] The self-service terminal for construction site workers includes a processor, memory, display and interaction components, ID card reading components, image acquisition components, and communication components. It also includes: a network status determination module, used to obtain network status parameters and determine the current network level; an identity verification module, used to verify the identity of workers; a business event generation module, used to generate business events based on business type, current network level, business risk level, and the status of preceding business events; a local evidence package generation module, used to generate local evidence packages associated with business events; a local persistent event queue module, used to write business events and local evidence packages into the local persistent event queue, and determine processing permissions based on the current network level and business risk level; a differentiated compensation synchronization module, used to read the business events to be synchronized and the corresponding local evidence packages after network recovery, and synchronize them to the cloud platform by calling compensation synchronization rules according to business type; a conflict resolution and state convergence module, used to perform conflict resolution and state convergence based on business event fields and local evidence package fields; a trusted session and page switching control module, used to establish trusted sessions and control the display interaction components to switch to the next business processing page; a local identity index library, used to store de-identified hash digest identity index data with version identifiers; and a local database, including an event queue storage area and an evidence package storage area.

[0140] The cloud platform receives synchronized business events and local evidence packages from the self-service labor terminal at the construction site, and performs status verification, review, and archiving on key fields such as contract number, contract template version, payroll number, wage confirmation batch, test paper version, and settlement statement number. In one implementation, the cloud platform returns the verification results to the self-service labor terminal at the construction site so that the terminal can perform status updates, rollback marking processing, and archiving control.

[0141] The on-site data acquisition terminal is preferably set up near the construction site gate, turnstile, or other suitable locations for collecting global image information. It is used to collect global image information and auxiliary identity verification information on-site, and send the collection results to the construction site labor self-service terminal.

[0142] The self-service terminal for construction site labor services cross-checks the identity verification results, personnel identification, event time, and terminal identification based on the data collection results sent by the on-site data collection terminal, and determines whether the business processing personnel are consistent with the on-site personnel and whether the business processing time is consistent with the on-site data collection time.

[0143] In a preferred embodiment, the cross-checking results can be used as input for updating the evidence completeness score.

[0144] In this embodiment, the system operation process is as follows: After a worker initiates a business processing request on the self-service terminal at the construction site, the identity verification module first outputs the identity verification result; the business event generation module and the local evidence package generation module generate the business event and the local evidence package; the local persistent event queue module writes both into the local database and simultaneously writes them into the delayed retry queue; when the network recovers, the differential compensation synchronization module reads the business event to be synchronized and the corresponding local evidence package and synchronizes it to the cloud platform; the conflict resolution and state convergence module performs conflict resolution and state update according to the event field and the evidence package field; the trusted session and page switching control module controls the switching of the next business page; if a field acquisition terminal is configured, the field acquisition terminal provides additional verification data.

[0145] Through the above structural configuration, the network status determination module, business event generation module, local evidence package generation module, local persistent event queue module, differentiated compensation synchronization module, and conflict resolution and state convergence module in the self-service construction site labor terminal work together to realize the processing from network status identification, business event generation, local evidence solidification, offline queue temporary storage, differentiated compensation synchronization after network restoration, to conflict resolution and business status update. Specifically, the current network level output by the network status determination module is used to control the business processing method and synchronization trigger conditions; business events and local evidence packages are written together as associated data into the local persistent event queue for synchronization processing after network restoration; the differentiated compensation synchronization module calls the corresponding synchronization rules according to the business type; the conflict resolution and state convergence module performs verification, conflict handling, and state update based on the business event field and the local evidence package field; and the auxiliary information collected by the on-site acquisition terminal can be used for identity verification result verification and evidence integrity update. Thus, the system can complete the continuous processing of labor services in weak network or network outage environments, and achieve orderly synchronization, conflict handling, and state convergence of multiple types of business data after network restoration.

[0146] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any ordinary changes and substitutions made by those skilled in the art within the scope of the technical solution of the present invention should be included within the protection scope of the present invention.

Claims

1. A closed-loop management method for weak network offline operations of a self-service labor terminal at a construction site, characterized in that, Includes the following steps: S1, obtain the network status parameters of the self-service labor terminal at the construction site, and determine the current network level based on the network status parameters; S2, based on the business processing request, verifies the identity of the personnel, and generates the corresponding business event and the local evidence package associated with the business event according to the business type, current network level, business risk level and the status of the preceding business event; S3 writes the business event and local evidence package into the local persistent event queue, and determines the processing authority of the business event based on the current network level and business risk level. S4, when network recovery is detected, read the business events to be synchronized and their corresponding local evidence packages in the local persistent event queue, call the corresponding compensation synchronization rules according to the business type, and synchronize the business events to be synchronized and their corresponding local evidence packages to the cloud platform. S5, during the synchronization process, based on the document version identifier, preceding event identifier, and current synchronization status in the business event, as well as the terminal identifier, device timestamp, and current business processing result summary in the local evidence package, performs duplicate verification, version consistency verification, preceding dependency order verification, and upstream and downstream state consistency verification on the business event to be synchronized, and performs conflict resolution and state convergence on the business event according to the verification results. S6, when a preceding business event enters a pending review state, the subsequent business events associated with the preceding business event are set to an associated pending review state; when the preceding business event is restored to a valid state, the corresponding unlock update is performed on the subsequent business events; when the preceding business event is determined to be in an invalid state, the corresponding invalidation update is performed on the subsequent business events.

2. The method for weak network offline closed-loop management of self-service labor terminals at construction sites according to claim 1, characterized in that, In step S1, the network status parameters include at least the link communication success rate, response latency, network interface availability status, and number of consecutive communication failures. The current network level includes at least online processing status, weak network restricted processing status, and offline local processing status.

3. The method for weak network offline closed-loop management of self-service labor terminals at construction sites according to claim 2, characterized in that, In step S2, during online processing, the identity of the workers is verified by combining ID card information with live facial recognition. In the case of processing under weak network conditions and offline local processing conditions, the offline temporary identity verification result is generated by matching ID card information with the local identity index database; After identity verification is successful, a trusted session is established, and the interactive components are controlled to switch to the next business processing page based on the pending tasks, the status of previous business events, and the business risk level.

4. The method for weak network offline closed-loop management of self-service labor terminals at construction sites according to claim 3, characterized in that, In steps S2 and S3, the business event includes at least the event number, business type identifier, personnel identifier, project identifier, terminal identifier, event time, document version identifier, current business status, current synchronization status, risk level, preceding event identifier, and trusted session identifier. The local evidence package includes at least one of the following: identity verification result summary, liveness detection result summary, ID card information summary, face capture summary, signature image summary, fingerprint image summary, business document version identifier, device timestamp, terminal identifier, previous event summary, and current business processing result summary.

5. The method for weak network offline closed-loop management of the self-service construction site machine according to claim 4, characterized in that, In step S3, determining the processing authority for business events includes: outputting local closed-loop results for low-risk businesses; outputting temporarily valid results for medium-risk businesses; and initially limiting high-risk businesses to pending confirmation processing, and updating them to temporarily valid pending review processing when preset review conditions are met.

6. The method for weak network offline closed-loop management of self-service labor terminals at construction sites according to claim 5, characterized in that, In step S4, the corresponding compensation synchronization rules are invoked according to the business type, including: for attendance-related businesses, the project identifier, personnel identifier, and identification time window are used as the deduplication primary key; for contract signing-related businesses, the contract number and document version identifier are used as the consistency verification primary key; for payroll confirmation-related businesses, the payslip number, personnel identifier, and confirmation batch are used as the primary key; for training and examination-related businesses, the test paper version, personnel identifier, and submission sequence number are used as the primary key; and for departure settlement-related businesses, the settlement slip number, personnel identifier, and signing date are used as the primary key.

7. The method for weak network offline closed-loop management of self-service labor service machines at construction sites according to claim 6, characterized in that, In step S4, the business events to be synchronized correspond to at least the enqueue time, retry count, most recent synchronization result, next retry time, priority identifier, review identifier, and subsequent dependent business identifier; the business events to be synchronized are read from the local persistent event queue in descending order of priority. After conflict resolution and state convergence are performed in steps S5 and S6, the status of the business events to be synchronized will be updated to final valid, pending review, associated pending review, or invalid.

8. A closed-loop management system for a self-service construction site worker assistance machine operating on a weak network, characterized in that: This includes self-service terminals for construction site workers and a cloud platform, among which: The self-service terminal for construction site labor services includes a processor, memory, display and interaction components, ID card reading components, image acquisition components, and communication components, and also includes: The network status determination module is used to acquire network status parameters and determine the current network level based on the network status parameters. The identity verification module is used to verify the identity of workers. The business event generation module is used to generate corresponding business events based on the business type, current network level, business risk level, and the status of preceding business events. The local evidence package generation module is used to generate local evidence packages associated with business events; The local persistent event queue module is used to write business events and local evidence packages into the local persistent event queue, and determine the processing authority of business events based on the current network level and business risk level. The differentiated compensation synchronization module is used to read the business events to be synchronized and the corresponding local evidence packages from the local persistent event queue when network recovery is detected, and to call the corresponding compensation synchronization rules according to the business type to synchronize the business events to be synchronized and the corresponding local evidence packages to the cloud platform. The conflict resolution and state convergence module is used to perform duplicate verification, version consistency verification, predecessor dependency order verification, and upstream and downstream state consistency verification on the business events to be synchronized during the synchronization process, based on the document version identifier, predecessor event identifier, and current synchronization state in the business events, as well as the terminal identifier, device timestamp, and current business processing result summary in the local evidence package. Based on the verification results, the module performs conflict resolution and state convergence on the business events. Specifically, when a preceding business event enters a pending review state, the conflict resolution and state convergence module is also used to set the subsequent business events associated with the preceding business event to an associated pending review state; when the preceding business event is restored to a valid state, the module performs the corresponding unlock update on the subsequent business events; and when the preceding business event is determined to be in an invalid state, the module performs the corresponding invalid update on the subsequent business events. The cloud platform is used to receive business events and local evidence packages synchronized from the self-service labor terminal at the construction site, and to perform status verification, review and archiving based on the received data.

9. The offline closed-loop management system for self-service construction site labor service machines according to claim 8, characterized in that, The self-service terminal for construction site labor services also includes a trusted session and page switching control module, a local identity index library, and a local database, wherein: The trusted session and page switching control module is used to establish a trusted session after identity verification is passed, and to control the switching of the display interaction components to the next business processing page according to the pending tasks, the status of previous business events and the business risk level. The local identity index store de-identified hash digest identity index data, along with a version identifier, to facilitate version updates with the cloud platform; The local database includes at least an event queue storage area and an evidence package storage area.

10. The offline closed-loop management system for self-service construction site labor service machines according to claim 9, characterized in that, It also includes on-site data collection terminals, which are used to cross-check the identity verification results, personnel identification, event time and terminal identification based on the data collection results sent by the on-site data collection terminals, and to determine whether the business handling personnel are the same as the on-site personnel and whether the business handling time is the same as the on-site data collection time based on the cross-checking results; The self-service terminal for construction site labor services serves as the main body for unified deduplication, unified version verification, and unified status convergence.

Images