An open laboratory equipment management system

Abstract

This invention discloses an open laboratory equipment management system, belonging to the field of open laboratory equipment management technology. It includes: an equipment management platform and at least one mobile terminal; the mobile terminal guides the collection of steps and records according to task scheduling information, and binds step nodes, evidence items, and state transition conditions based on a task-evidence-state constraint matrix. After multiple security checks, it generates a field verification evidence packet, which is uploaded to the equipment management platform when the network is available; when the network is unavailable, it performs a state change permission judgment and writes it to an offline ledger for later re-upload after passing the judgment; the equipment management platform evaluates the received field verification evidence packet and all records in the offline ledger, and sends the evaluation result back to the mobile terminal. This invention binds step nodes, evidence items, and equipment state transition conditions, and can determine whether the field evidence is sufficient to support the equipment state change in online, offline, and concurrent scenarios.

Description

Technical Field

[0001] This invention belongs to the technical field of open laboratory equipment management, and specifically relates to an open laboratory equipment management system. Background Technology

[0002] Open laboratory equipment is characterized by its variety, frequent sharing, cross-course / cross-project circulation, and the coexistence of multiple roles among users and managers. Current management methods, primarily relying on manual registration, simple QR code registration, or ordinary asset management systems, generally suffer from the following problems:

[0003] 1. Inconsistent processes and frequent omissions: Borrowing, returning, inventorying, and maintenance often lack standardized step-by-step guidance, and key inspection items and evidence items are easily overlooked, leading to discrepancies between accounts and actual items and disputes over responsibility; 2. Weak network / network outage affects continuity: When the on-site network is unstable, the registration is interrupted, which leads to duplicate entries and disordered order when re-entering data afterward, making it difficult to ensure consistency.

[0004] 3. Disconnect between fixed task lists and actual business status: During peak teaching periods and in weak network environments in open laboratories, equipment status transitions are not a single registration action, but are affected by factors such as equipment health status, calibration validity period, completeness of accessories and consumables, user roles, and the quality of on-site evidence. If only fixed task lists or ordinary offline re-upload mechanisms are used, problems such as "items on the list are completed but not enough to prove the legality of the status change", "offline re-upload is uploaded but cannot prove that it is within the pre-authorized scope of the platform", and "multiple concurrent events can be sorted by time but it is impossible to determine which one conforms to the actual equipment status transition path" are likely to occur. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides an open laboratory equipment management system that binds step nodes, evidence items, and equipment state transition conditions, and can determine whether on-site evidence is sufficient to support equipment state changes in online, offline, and concurrent scenarios.

[0006] This invention provides the following technical solution: An open laboratory equipment management system includes an equipment management platform and at least one mobile terminal; the mobile terminal includes a human-computer interaction module, a data acquisition and positioning module, a local verification module, an on-site verification data packet generation module, a local status shadow machine, and a communication module; the equipment management platform includes a configuration module, a constraint generation module, and an equipment status service module. The configuration module is used to configure task orchestration information, compliance checklists, and policy packages corresponding to the operation type; The constraint generation module is used to generate a task-evidence-state constraint matrix based on the dynamic context parameters of the device to be managed, which limits the mapping relationship between step nodes, evidence items, state transition conditions and disposal actions. The human-computer interaction module is used to receive the user's operation type on the managed device, generate a guidance path based on the task arrangement information, and collect the user's input data at all step nodes to form a step record. The data acquisition and positioning module is used to collect user location information, operation time, and identification information of the devices to be managed. The local verification module is used to perform multiple security verifications, including: gating the collected information according to the policy package; verifying the compliance of the step records according to the compliance checklist and the task-evidence-state constraint matrix; and verifying the sufficiency of evidence items in the step records. The on-site verification evidence package generation module is used to summarize the equipment identification information, operation type, user location information and step record to generate an on-site verification evidence package after passing multiple security verifications. The local state shadow machine is used to verify whether the on-site verification data packet meets the state change permission conditions when the network is unavailable. If it does, the on-site verification data packet is assigned a sequence number, idempotent key and validity period and then written to the offline ledger. The communication module is used to upload all records of the real-time generated on-site verification data packets or offline ledgers to the device status service module when the network is available; The Equipment Status Service module is used to evaluate the equipment status changes of all records in the received on-site verification data package and offline ledger, and return the evaluation results to the Human-Machine Interaction module.

[0007] Optionally, the device management platform also includes a risk scoring module, which is used to count several risk indicators of the mobile terminal within a preset sliding window and integrate all risk indicators to obtain a risk score; the risk indicators include the number of overdue periods, the number of out-of-bounds periods, the frequency of anomalies, the proportion of missing evidence, or the conflict occurrence rate.

[0008] Optionally, the configuration module is also used to configure conflict reload rules, offline lease tokens, and device state transition diagrams; The device status service module is used to evaluate the device status change of all records in the on-site verification evidence package or offline ledger. Specifically, it performs conflict reloading on all records in the on-site verification evidence package and offline ledger according to conflict reloading rules, offline lease tokens, device status transition diagrams, platform trusted time sequence and risk scores, and generates a status change evaluation result in the form of a reason code. Then, it triggers a handling action based on the status change evaluation result. The local state shadow machine verifies whether the on-site verification data packet meets the state change permission conditions when the network is unavailable, based on the issued offline lease token.

[0009] Optionally, the configuration module is also used to count all risk scores within a preset period, and adjust the pass requirements of each rule in the strategy package after the risk score exceeds a set threshold range.

[0010] Optionally, the constraint generation module is used to generate a task-evidence-state constraint matrix based on the dynamic context parameters of the device to be managed. Specifically, it binds a set of evidence items and state transition conditions to each step node of the task orchestration information based on the current state of the device, the device's digital passport information, the course plan, the user role, the operation type, and the historical risk score.

[0011] Optionally, the task orchestration information in the configuration module includes: operation type, step node set, and prerequisites; the step node set includes: step number, step name, and input field set. The compliance checklist includes at least one of the following categories: mandatory fields, mandatory photo fields, mandatory measurement fields, and mandatory signature fields. The policy package includes: time period rules and / or fence rules, as well as the pass requirements for the rules.

[0012] Optionally, the specific steps for the local verification module to perform gate control determination are as follows: determine whether the operation time, the identification information of the device to be managed, and the user location information meet the preset requirements according to the corresponding rules of the policy package. If they meet the requirements, the gate control determination is passed; otherwise, the gate control determination is not passed, and the corresponding failure reason code is output in the human-computer interaction module. The specific steps for the local verification module to perform compliance verification are as follows: determine whether the step record has completed all items of the compliance checklist. If not, drive correction and re-perform multiple security verifications based on the corrected content. If completed, determine whether the step record meets the state transition conditions in the task-evidence-state constraint matrix. If it does, the compliance verification passes; otherwise, the compliance verification fails, and the corresponding failure reason code is output in the human-computer interaction module. The specific steps for the local verification module to perform evidence sufficiency scoring verification are as follows: First, obtain several sufficiency indicators of the evidence items in the step record, and then fuse them to obtain an evidence sufficiency score. The several sufficiency indicators include at least two of the following: image evidence completeness, measurement data qualification, location credibility, device token consistency, or operation time consistency. If the evidence sufficiency score is greater than the state change threshold, the evidence sufficiency score verification is passed; otherwise, it is determined whether the evidence sufficiency score is greater than the correction threshold. If it is greater than the correction threshold, correction is driven, and multiple security verifications are performed again based on the corrected content. If it is less than the correction threshold, the evidence sufficiency score verification is not passed, and the corresponding failure reason code is output in the human-computer interaction module.

[0013] Optionally, the configuration module is also used to configure the destination token and disclosure policy; The human-computer interaction module performs field-level minimal collection of step records based on the target token, and generates a hierarchical desensitized view based on the desensitization template of the disclosure strategy for display or uploading. The on-site verification data package generation module performs field-level minimization collection on the on-site verification data package based on the destination token, and generates a hierarchical desensitized view based on the desensitized template of the disclosure strategy for display or uploading.

[0014] Optionally, the device management platform further includes an audit module, and the mobile terminal further includes a security module; The audit module is used to package the on-site verification evidence package summary, equipment status change assessment result, status change assessment timestamp, platform signature information and terminal signature verification result into a platform evidence package; The security module is used to construct an audit chain for all records of the on-site verification evidence package or offline ledger, and to receive the platform evidence package; the audit chain includes: the version number of the task-evidence-state constraint matrix, the evidence sufficiency score, and the version of all configuration information corresponding to the current operation type.

[0015] Optionally, the device management platform also includes a maintenance module for updating the device's digital passport information after the user completes the operation process for the device to be managed.

[0016] Compared with the prior art, the beneficial effects of the present invention are: (1) First, this invention, through the task scheduling information and compliance checklist issued by the equipment management platform, can realize step-by-step SOP guidance for operations such as borrowing, returning, inventory, maintenance, and calibration, thereby reducing reliance on manual experience and reducing omissions and misoperations. Second, this invention adopts multiple security checks of "gating judgment + compliance verification + evidence sufficiency scoring verification", which can not only avoid state transitions without evidence, exceeding authority, or lacking evidence, but also quantify and integrate the quality of evidence, so that "whether state change is allowed" is upgraded from a simple omission judgment to a calculable, verifiable, and interpretable evidence sufficiency judgment. Furthermore, this invention directly binds step nodes, evidence items, and device state transition conditions by introducing a task-evidence-state constraint matrix. This ensures that each piece of on-site data collection serves a specific state change condition, thereby avoiding a disconnect between a fixed list and the actual business state and improving the identifiability of technical constraint relationships. Simultaneously, the offline ledger records of this invention include sequence numbers, idempotent keys, and expiration dates. After network recovery, these records can be re-uploaded sequentially, improving the continuity of operations in weak / out-of-network scenarios and reducing duplicate entries and sequence errors caused by re-entry. The device management platform performs idempotent entries based on idempotent keys, effectively suppressing anomalies such as duplicate borrowing and return caused by duplicate submissions, improving accounting consistency and system robustness. Finally, this invention limits the device scope, operation scope, state transition scope, and maximum number of events for offline events through a local state shadow machine, and performs state replay verification after network recovery, avoiding the problem that ordinary offline re-entry cannot prove the pre-authorized scope and state legality.

[0017] (2) The equipment management platform of this invention automatically adjudicates conflict events based on conflict reload rules, avoiding state conflicts and unclear responsibilities caused by peak concurrency. Specifically, it filters the legal state paths of conflict events through the equipment state transition diagram, so that conflict arbitration no longer relies solely on manual priority or time sequence, and then combines the legality of state edges, lease validity, evidence sufficiency, credible timestamps, and signature verification results to complete an interpretable adjudication. In addition, the state assessment results of this invention are returned in the form of reason codes, so that the mobile terminal side prompts, rollbacks, or freezes have a consistent standard, improving the interpretability and operability of anomaly handling. Furthermore, the mobile terminal of this invention signs the on-site verification evidence package and constructs an audit chain, and the equipment management platform generates a platform evidence package, improving the verifiability of audit traceability and the ability to review disputes. Finally, based on the purpose token and disclosure strategy, the mobile terminal performs field-level minimal collection and hierarchical desensitization display, reducing the risk of excessive collection and unnecessary disclosure of personal information, and fully meeting the compliance requirements of universities. Attached Figure Description

[0018] Figure 1 This is a structural block diagram of the open laboratory equipment management system of the present invention. Detailed Implementation

[0019] The present invention will be further described below with reference to the accompanying drawings. The following embodiments are only used to more clearly illustrate the technical solutions of the present invention and should not be used to limit the scope of protection of the present invention. It should be noted that the term "comprising" and any variations thereof in the specification, claims and the above-mentioned drawings of the present invention are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products or devices.

[0020] like Figure 1 As shown, an open laboratory equipment management system includes an equipment management platform and a mobile terminal.

[0021] The mobile terminal includes a human-computer interaction module, a data acquisition and positioning module, a local verification module, an on-site verification data packet generation module, a local status shadow machine, a communication module, and a security module.

[0022] The equipment management platform includes a configuration module, a constraint generation module, an equipment status service module, a risk scoring module, an audit module, and a maintenance module.

[0023] I. Configuration Module.

[0024] This is used to configure the task orchestration information TaskGraph, compliance checklist ChecklistPack, policyPack, purpose token, and disclosure policy corresponding to the operation type op_type, as well as to configure the conflict reload rule ConflictRule, offline lease token, and device state transition graph StateTransitionGraph.

[0025] The TaskGraph orchestration information includes: operation type (op_type), a set of step nodes, and preconditions; the set of step nodes includes: step number, step name, and a set of input fields. Preconditions refer to the business or technical conditions that must be met before a certain step node can be executed.

[0026] The compliance checklist pack includes at least one of the following categories: mandatory fields, mandatory photo fields, mandatory measurement fields, and mandatory signature fields.

[0027] The PolicyPack includes time-based rules and / or fence rules, as well as the pass requirements for these rules.

[0028] The ConflictRule is a set of rules used to handle concurrent or conflicting operations that occur on the same device within a preset time window.

[0029] The OfflineLeaseToken includes: lease number, device location range, user or group identifier, allowed operation type op_type, allowed state transition set, maximum number of offline events, lease start and end time, and platform signature.

[0030] The StateTransitionGraph is a set of predefined device state nodes and valid state edges, used to determine whether the starting state, target state (state_target), and operation type (op_type) of a candidate event (user operation on the managed device) constitute a valid path.

[0031] The PurposeToken explicitly states the legitimate purpose for which the current operation is allowed to collect data, as well as the scope of data collection bound to that purpose.

[0032] The DisclosurePolicy is used to limit the set of fields that can be collected, displayed, or uploaded under different purposes and roles, as well as the de-identification templates. The DisclosurePolicy can further limit the whitelist of fields and retention rules. The retention rules can set the retention period for original images and location data, and erase or downgrade the data upon expiration (only the traceability requirement needs to be met).

[0033] II. Constraint Generation Module.

[0034] It is used to generate a TaskEvidenceStateMatrix based on the dynamic context parameters of the device to be managed, which defines the mapping relationship between step nodes, evidence items, state transition conditions and disposal actions.

[0035] The specific steps for generating the TaskEvidenceStateMatrix are as follows: Based on the device's current state (state_cur), device digital passport information, course plan, user role, operation type (op_type), and historical risk score (RiskScore), bind an evidence set (EvidenceSet) and a state transition condition (StateCondition) to each step node of the task orchestration information TaskGraph. The TaskEvidenceStateMatrix can also include a matrix version number so that the audit module can trace back the constraint version used for each state change. The risk score (RiskScore) is obtained based on the risk indicators of the mobile terminal within a preset window.

[0036] More specifically, the system reads the device's current state (state_cur), operation type (op_type), device digital passport information, user role, course plan, and historical risk score (RiskScore) to determine the target state (state_target) that the user's current operation is allowed to reach. It also binds an evidence set (EvidenceSet) and a state transition condition (StateCondition) to each step node in the task orchestration information (TaskGraph).

[0037] The EvidenceSet includes at least one or more of the following: image evidence, measurement data, signature information, location data, and device identification data; the StateCondition includes at least one or more of the following: evidence integrity condition, measurement threshold condition, attachment consistency condition, calibration validity condition, and maintenance release condition.

[0038] The device's digital passport information includes CalibrationPack, MainPack, HealthPack, and AccessoryPack. CalibrationPack records calibration expiration dates, calibration methods, standard part numbers, and results. MainPack records maintenance work orders, component replacements, fault codes, and handling procedures. HealthPack records self-test results and key indicator trends. AccessoryPack records a list of accessories and consumables and their associated relationships.

[0039] The CoursePlan is used to determine the available operating time of the equipment, and the CoursePlan can be configured through the configuration module.

[0040] III. Human-Computer Interaction Module.

[0041] It is used to receive the user's operation type op_type for the managed device, generate a guide path based on the task orchestration information TaskGraph, and collect the user's input data at all step nodes to form a step record StepRecord.

[0042] The purpose of generating a guide path is to guide users through the steps of borrowing, returning, inventorying, maintaining, or calibrating. The method for generating the guide path follows existing technologies.

[0043] StepRecord is the user input data collected by the human-computer interaction module at each step node. Each record in StepRecord includes at least the step number, input data, data input time (corresponding to the current step), collection source, and optional evidence digest (such as image hash value, measurement value digest, etc.).

[0044] The steps for a user to borrow a device can be represented as follows: identity verification → reading device identification → photographing the device's appearance and nameplate → checking accessories and consumables → entering necessary measurement items → electronic signature → submitting the verification package.

[0045] In some other embodiments, to reduce the risk of excessive collection and unnecessary disclosure of personal information and meet the compliance requirements of universities, the human-computer interaction module performs field-level minimal collection of the StepRecord based on the PurposeToken, and generates a hierarchical de-identified view for display based on the de-identification template of the DisclosurePolicy. Before collecting user input data, the evidence items in the TaskEvidenceStateMatrix can be cross-validated with the sub-field whitelist in the DisclosurePolicy, and fields not necessary for the current purpose are not included in the collection.

[0046] IV. Data Acquisition and Positioning Module.

[0047] It is used to collect user location information geo, operation time t_local, and identification information of the device to be managed.

[0048] The operation time t_local is usually the time it takes to obtain the user's location information geo, but the operation time t_local can also be the time it takes to execute the first step node.

[0049] The identification information of the device to be managed can be collected using a camera / QR code, or NFC or RFID readers. The user's location information geo can be obtained by using GNSS, Wi-Fi, Bluetooth positioning or base station positioning of the mobile terminal. The user's location information geo usually also includes the location accuracy geo_acc, which can be determined based on existing technologies.

[0050] If the identification information of the device to be managed is based on camera photos, the target shooting area, shooting angle or key component area can be restricted by the TaskEvidenceStateMatrix. During the data collection process, guidance prompts can be superimposed in the human-computer interaction to complete the operation point verification or image verification.

[0051] After parsing the identification information of the device to be managed, a device token is obtained. The device token is uniquely associated with the device in the asset ledger of the device management platform. The device token includes at least the device identifier. In some other embodiments, it may also include a replay prevention field (nonce or counter) and verification information (verification code or signature).

[0052] V. Local verification module.

[0053] Used for multiple security checks.

[0054] Multiple security checks include: gating the collected information based on the PolicyPack; verifying the compliance of the StepRecord based on the ChecklistPack and the TaskEvidenceStateMatrix; and verifying the evidence items of the StepRecord with an EvidenceSufficiencyScore.

[0055] 1. The specific steps for gate control determination are as follows: Based on the corresponding rules in the PolicyPack, determine whether the operation time t_local, the identification information of the device to be managed, and the user location information geo meet the preset requirements. If they do, the gating is passed; otherwise, the gating is not passed, and the corresponding failure reason code ReasonCode is output in the human-computer interaction module.

[0056] When the PolicyPack includes fence rules, the fence rules can be expressed as circular fences or polygonal fences. The PolicyPack must at least provide the coordinates of the fence center point / vertex, the allowed radius or boundary, the positioning accuracy threshold, and the allowed number of positioning deviations. Fence gating is considered successful when the location information (geo) falls within the fence and the positioning accuracy (geo_acc) is less than or equal to the set threshold; otherwise, a ReasonCode (out of bounds) failure code is output.

[0057] When the PolicyPack rules include time period rules, the time period rules specify the operable time periods. and allowable time error When the operation time t_local is located If the time period rule is passed, the system will determine whether the device is eligible for use; otherwise, it will output a ReasonCode (Expiration). The operable time period is determined based on the current status of the device under management and the CoursePlan. For example, the device under management may only be allowed to be borrowed from 8:00 to 16:00 under the current status and CoursePlan. and These are the start and end times of the operable period, respectively.

[0058] If the PolicyPack includes both time-based rules and fence rules, then the gating decision will only pass if both time-based rules and fence rules are passed; otherwise, the gating decision will fail.

[0059] 2. The specific steps for compliance verification are as follows: The step record determines whether StepRecord has completed all items of the compliance checklistPack. If not, it drives correction, generates a guide step for missing data in the human-computer interaction module, and performs multiple security checks again based on the corrected content. If it has completed, it determines whether StepRecord satisfies the state transition conditions in the TaskEvidenceStateMatrix. If it does, the compliance check passes; otherwise, the compliance check fails, and the ReasonCode is output in the human-computer interaction module.

[0060] The determination of whether StepRecord has completed all items of the compliance checklistPack is as follows: check one, several, or all of the following: completeness of required fields, completeness of required photos, compliance of required measurements, and satisfaction of required signatures. The specific determination is based on the compliance checklistPack.

[0061] If a certain piece of evidence is missing or does not meet the state transition conditions of the TaskEvidenceStateMatrix, the compliance check will fail.

[0062] 3. The specific steps for verifying the Evidence Sufficiency Score are as follows: First, obtain several sufficiency indicators for the evidence items in the StepRecord, and then fuse them to obtain the EvidenceSufficiencyScore. If the EvidenceSufficiencyScore is greater than the state change threshold, the EvidenceSufficiencyScore is verified. Otherwise, it is determined whether the EvidenceSufficiencyScore is greater than the correction threshold. If it is greater than the correction threshold, correction is driven, a guide step for missing data is generated in the human-computer interaction module, and multiple security checks are performed again based on the corrected content. If it is less than the correction threshold, the EvidenceSufficiencyScore verification fails, and the corresponding failure reason code ReasonCode is output in the human-computer interaction module.

[0063] Several sufficiency indicators include at least two of the following: image evidence completeness, measurement data compliance, signature satisfaction, location credibility, device token consistency, or operation time consistency. The method of combining several sufficiency indicators to obtain the evidence sufficiency score is usually weighted fusion.

[0064] For example, the sufficiency of evidence score The calculation formula is: ; in, For the completeness of image evidence, To measure the compliance of the measurement data, To ensure approval satisfaction, For location credibility, For device token consistency, To ensure consistent operation time, , , , , and respectively , , , , and The corresponding weights, and their sum is 1.

[0065] For borrowing operations, the weights of device token consistency, location credibility, and signature satisfaction may be higher than the weight of image evidence integrity; for returning operations, the weights of image evidence integrity, measurement data qualification, and device token consistency may be higher than the weight of signature satisfaction; for maintenance or calibration operations, the weights of measurement data qualification and signature satisfaction may be higher than the corresponding weights for ordinary borrowing and returning operations. The methods for obtaining image evidence integrity, measurement data qualification, signature satisfaction, location credibility, device token consistency, or operation time consistency can be determined based on existing technologies.

[0066] The status change threshold is used to determine whether the EvidenceSufficiencyScore is sufficient to directly support the status change of the current operation type op_type; the correction threshold is used to determine whether to allow entry into the evidence correction process.

[0067] When multiple security checks fail, further actions can be triggered based on the ReasonCode, including outputting a status change blocking message, entering a correction process, triggering dual-person confirmation, freezing the system, or generating a review work order.

[0068] VI. On-site verification data package generation module.

[0069] This is used to generate a field verification data package, ProofPack, by summarizing device identification information, operation type op_type, location information geo, and step record StepRecord after passing multiple security checks.

[0070] In some other embodiments, in order to reduce the risk of excessive collection and unnecessary disclosure of personal information and meet the compliance requirements of universities, field-level minimal collection is performed based on the PurposeToken, that is, the device identification information, operation type op_type, location information geo and step record StepRecord are collected in a minimal manner, and a hierarchical de-identified view is generated based on the de-identification template of the DisclosurePolicy and uploaded.

[0071] 7. Local State Shadow Machine.

[0072] Used to verify whether the on-site verification data packet ProofPack meets the state change permission conditions when the network is unavailable. If it does, the on-site verification data packet ProofPack is assigned a sequence number seq, an idempotent key dedup_key, and an expiration date ttl before being written to the offline ledger OfflineLedger.

[0073] The local state shadow machine is a local predicted state structure established based on the device state most recently confirmed by the device management platform. It includes device identifier, platform confirmed state, local predicted state, most recent platform confirmed time, and event queue to be retransmitted. It is used to constrain the state legality of continuous operations during offline periods.

[0074] The local state shadow machine, based on the OfflineLeaseToken issued by the device management platform, verifies whether the on-site verification proof packet (ProofPack) meets the state change permission conditions when the network is unavailable. Specifically, the on-site verification proof packet (ProofPack) is only allowed to be written to the OfflineLedger if both the current operation type (op_type) and the target state transition of the device to be managed fall within the limits of the OfflineLeaseToken. Each on-site verification proof packet (ProofPack), combined with its sequence number (seq), idempotent key (dedup_key), and expiration date (ttl), becomes a record in the OfflineLedger.

[0075] The OfflineLedger is a local ledger used to temporarily store proof packets (ProofPack) and their processing status when the mobile terminal network is unavailable. The input fields for the idempotent key (dedup_key) include: device identifier, operation type (op_type), user / group identifier, sequence number (seq), and time window identifier. The idempotent key (dedup_key) is obtained by combining all input fields and generating a digest.

[0076] Sequence number seq: A consistency field used to constrain the order of retransmissions. It can be an incrementing sequence number or a monotonically increasing sequence number within the same terminal / same task range.

[0077] Validity period (TTL): This is used to limit the acceptable time range for offline events (ProofPack in the OfflineLedger) on the device management platform. Offline events that exceed the validity period (TTL) will directly enter the review channel or be rejected for accounting and the corresponding failure reason code (ReasonCode) will be returned.

[0078] Time window identifier: To prevent minor differences in timestamps from generating different idempotent keys for the same business operation, the operation time t_local is "bucketed" or "rounded" according to a preset time length (e.g., 1 hour, 1 day) to obtain an identifier representing that time window. This time window identifier will be used as part of the idempotent key dedup_key, so that multiple requests for the same device and the same operation type within the same time window will generate the same idempotent key if other key fields are the same, thus being judged as duplicate requests.

[0079] The sequence number (seq), idempotent key (dedup_key), and time-to-live (TTL) expiration are used to ensure the order of retransmission, avoid duplicate entries, and constrain the validity of offline events. After network recovery, the communication module retransmits events in the order of the sequence number (seq). The device management platform performs idempotent entries based on the idempotent key (dedup_key): processed events are directly returned with existing results, while unprocessed events are entered according to rules and the device status is updated. For events with expired TTL, the device management platform can refuse entry or guide them to the review channel and return the corresponding ReasonCode. Through the combination of "sequence number (seq), idempotent key (dedup_key), and time-to-live (TTL)," accounting consistency and controllability can still be maintained even in weak network scenarios.

[0080] 8. Communication Module.

[0081] This is used to upload all records of the real-time generated on-site verification data package ProofPack or the offline ledger OfflineLedger to the device status service module when the network is available.

[0082] During the upload process, a signature is generated for each record in the on-site verification evidence package ProofPack or the offline ledger. The input fields for the signature information include: device identifier, operation type op_type, user / group identifier user_id / group_id, operation time t_local, location information geo, and step record digest StepRecord. The signature algorithm can be implemented using either digital signature or message authentication code, and the key can be stored in the security module or trusted execution environment.

[0083] 9. Equipment Status Service Module.

[0084] This module is used to evaluate device status changes for all records in the received on-site verification evidence package ProofPack and offline ledger, and then returns the evaluation results to the human-machine interaction module.

[0085] The evaluation results are returned to the human-computer interaction module in the form of a ReasonCode. The ReasonCode indicates the reasons and subsequent actions for events such as pass / reject / overdue / out of bounds / conflict freeze / requires dual confirmation / requires manual review. Freezing is a temporary restriction set by the device management platform for the managed device when there is offline retransmission, concurrent conflict, insufficient evidence, or the status replay verification cannot uniquely determine the legitimate status path. After freezing, normal status changes of the device are prohibited; only dual confirmation or manual review processes are allowed to lift the freeze.

[0086] The specific steps for equipment status change assessment are as follows: Based on the ConflictRule, OfflineLeaseToken, StateTransitionGraph, Platform Trusted Time Sequence, and RiskScore, all records in the ProofPack and OfflineLedger are reloaded to resolve conflicts. After generating a state change assessment result in the form of a ReasonCode, a handling action (such as triggering a device state change or restricting a device state change) is triggered based on the state change assessment result.

[0087] The ConflictRule can define the conflict detection time window, adjudication priority, and freeze handling mechanism. When concurrent events cannot be adjudicated automatically, the device status is frozen and a double confirmation or manual review is triggered. The review result is sent back to the terminal in the form of ReasonCode and archived in the audit chain, thereby ensuring consistency between accounts and actual situation and traceability of responsibility.

[0088] The StateTransitionGraph associates state nodes such as idle, reserved, borrowed, in use, awaiting return inspection, returned, awaiting maintenance, under maintenance, awaiting calibration, and frozen state with legal state edges. For multiple candidate events within a conflict time window, filtering is performed based on state transition legality, offline lease validity, TTL validity, signature verification result, EvidenceSufficiencyScore, and platform trusted time order. If a legal path cannot be uniquely determined, the system enters a frozen state and generates a review work order.

[0089] The specific steps for conflict overloading are as follows: Sort all offline ledger records and online verification evidence packages (ProofPack) within the preset time window according to their offline order or platform-trusted time order. Remove candidate events that do not conform to the valid state edges of the device's StateTransitionGraph; remove candidate events with invalid offline lease tokens, expired validity periods, failed terminal signature verification, or risk scores exceeding a set threshold; reload the remaining candidate events according to the ConflictRule. Removed candidate events will directly return a ReasonCode or trigger a review or freeze.

[0090] In some embodiments, the ConflictRule is as follows: events with completed verification and complete evidence take precedence over events with missing evidence; "return / entry" of the same device takes precedence over "borrowing / out" to avoid negative inventory; earlier sequence number seq takes precedence over later sequence number seq; if a decision still cannot be made, the device is frozen and a double confirmation is triggered; after the double confirmation is passed, a review signature is generated and the freeze is lifted; otherwise, the decision is rejected and a ReasonCode is output; when multiple candidate events meet the conditions and the state path cannot be uniquely determined, the device is frozen and a review work order is generated.

[0091] The input for conflict reloading includes at least the operation time t_local, sequence number seq, evidence integrity flag (satisfying multiple security checks), and current device status. The output for conflict reloading includes at least the following: adjudication type (automatic / dual confirmation / manual review), adjudication result (allow / reject / rollback / freeze), and reason code. When a conflict cannot be automatically adjudicated, the platform sets the device status to frozen.

[0092] It is worth noting that each record in the OfflineLedger needs to undergo terminal signature verification before being uploaded to the device management platform. If the verification fails, the corresponding ReasonCode is returned and the entry is rejected or the review process begins. Only if the verification is successful will the idempotent entry, conflict detection, and status update be performed.

[0093] 10. Risk Scoring Module.

[0094] This is used to collect several risk indicators of a mobile terminal within a preset sliding window, and to combine these risk indicators to obtain a risk score, RiskScore.

[0095] Risk indicators include the number of overdue periods, the number of out-of-bounds violations, the frequency of anomalies, the proportion of missing evidence, or the conflict rate. The risk score, RiskScore, can be implemented using a weighted summation of normalized sub-scores or an equivalent calculation method, with weights and thresholds being configurable parameters.

[0096] The configuration module is also used to count all risk scores (RiskScore) within a preset period, and adjust the pass requirements of each rule in the PolicyPack after the RiskScore exceeds the set threshold range, i.e., drive the threshold to tighten or loosen, so as to form an adaptive convergence of the gating verification threshold.

[0097] The proportion of missing evidence is determined by the number of events where the EvidenceSufficiencyScore is below the corresponding threshold. This embodiment requires saving the RiskScore to facilitate the generation of the TaskEvidenceStateMatrix, thereby allowing high-risk devices, users, or course scenarios to have higher evidence requirements or stricter state change thresholds.

[0098] Within a sliding window (e.g., 7-30 days), the number of overdue periods, out-of-bounds periods, missing evidence periods, conflict periods, and abnormal work orders are counted separately. Each item is normalized to the upper limit to obtain a sub-score, and a risk score is synthesized according to the weights. The risk score can also be determined by weighted summation of elements: calculate sub-scores for elements such as overdue periods, out-of-bounds periods, missing evidence, conflict rate, and abnormal work orders, and synthesize a total score according to the weights.

[0099] XI. Security Module.

[0100] This is used to build an audit chain for on-site verification of the ProofPack or the OfflineLedger, and to receive the EvidencePack from the platform. The audit chain includes: the version number of the TaskEvidenceStateMatrix, the EvidenceSufficiencyScore, and the version of all configuration information corresponding to the current operation type op_type of the mobile terminal.

[0101] 12. Audit Module.

[0102] This is used to package the ProofPack summary of the on-site verification evidence package, the equipment status change assessment result, the status change assessment timestamp, the platform signature information, and the terminal signature verification result to generate the platform evidence package EvidencePack.

[0103] The audit module generates a platform evidence package, EvidencePack, which includes at least a summary of the on-site verification evidence package, ProofPack, a trusted platform timestamp and platform signature information, and a terminal signature verification result. This is used for verifiable auditing and to correct local time drift on mobile terminals.

[0104] Thirteen, Maintenance Module.

[0105] Update the device's digital passport information after the user completes the operation process for the managed device.

[0106] The specific steps for a user to perform equipment management operations using the open laboratory equipment management system of the present invention are as follows: S1: Obtain TaskGraph, ChecklistPack, PolicyPack, and TaskEvidenceStateMatrix. Guide the collection of StepRecords according to TaskGraph, and bind the step nodes, evidence items, and state transition conditions according to TaskEvidenceStateMatrix.

[0107] S2: Read the device identifier to generate a device token (DeviceToken), obtain the location information (geo), and perform gating judgment based on the policy pack (PolicyPack); calculate the evidence sufficiency score (EvidenceSufficiencyScore) to determine whether the step record (StepRecord) is sufficient to support the target device state change; and perform compliance verification on the step record (StepRecord) according to the compliance checklist (ChecklistPack) and the task-evidence-state constraint matrix (TaskEvidenceStateMatrix).

[0108] S3: After passing the gating judgment, compliance verification and the evidence sufficiency score (EvidenceSufficiencyScore) is greater than the set threshold, the device identification information, operation type (op_type), user location information (geo), and step record (StepRecord) are summarized to generate the on-site verification evidence package (ProofPack).

[0109] S4: If the network is available, upload the on-site verification data packet ProofPack to the device management platform to request a device status change. If the network is unavailable, verify whether the status change is allowed based on the OfflineLeaseToken and the local status shadow machine. If it is, add the sequence number seq, idempotent key dedup_key and validity period ttl to the offline ledger OfflineLedger, and re-upload it in order after the network is restored.

[0110] S5: Process concurrent conflicts and output the reason code according to the ConflictRule and in combination with the device state transition graph, offline lease token, platform trusted time order and risk score; S6: Update device digital passports and archive audit chains.

[0111] For more detailed information on the above methods, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.

[0112] Those skilled in the art will clearly understand that the techniques in the embodiments of the present invention can be implemented using software and necessary general-purpose hardware platforms. The above are merely preferred embodiments of the present invention, and the scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should be considered within the scope of protection of the present invention.

Claims

1. An open laboratory equipment management system, characterized in that, It includes an equipment management platform and at least one mobile terminal; the mobile terminal includes a human-machine interaction module, a data acquisition and positioning module, a local verification module, a field verification data packet generation module, a local status shadow machine, and a communication module; the equipment management platform includes a configuration module, a constraint generation module, and an equipment status service module; The configuration module is used to configure task orchestration information, compliance checklists, and policy packages corresponding to the operation type; The constraint generation module is used to generate a task-evidence-state constraint matrix based on the dynamic context parameters of the device to be managed, which limits the mapping relationship between step nodes, evidence items, state transition conditions and disposal actions. The human-computer interaction module is used to receive the user's operation type on the managed device, generate a guidance path based on the task arrangement information, and collect the user's input data at all step nodes to form a step record. The data acquisition and positioning module is used to collect user location information, operation time, and identification information of the devices to be managed. The local verification module is used to perform multiple security verifications, including: gating the collected information according to the policy package; verifying the compliance of the step records according to the compliance checklist and the task-evidence-state constraint matrix; and verifying the sufficiency of evidence items in the step records. The on-site verification evidence package generation module is used to summarize the equipment identification information, operation type, user location information and step record to generate an on-site verification evidence package after passing multiple security verifications. The local state shadow machine is used to verify whether the on-site verification data packet meets the state change permission conditions when the network is unavailable. If it does, the on-site verification data packet is assigned a sequence number, idempotent key and validity period and then written to the offline ledger. The communication module is used to upload all records of the real-time generated on-site verification data packets or offline ledgers to the device status service module when the network is available; The Equipment Status Service module is used to evaluate the equipment status changes of all records in the received on-site verification data package and offline ledger, and return the evaluation results to the Human-Machine Interaction module.

2. The open laboratory equipment management system according to claim 1, characterized in that, The device management platform also includes a risk scoring module, which is used to count several risk indicators of mobile terminals within a preset sliding window and integrate all risk indicators to obtain a risk score; the risk indicators include the number of overdue periods, the number of out-of-bounds periods, the frequency of anomalies, the proportion of missing evidence, or the conflict occurrence rate.

3. The open laboratory equipment management system according to claim 2, characterized in that, The configuration module is also used to configure conflict reload rules, offline lease tokens, and device state transition diagrams. The device status service module is used to evaluate the device status change of all records in the on-site verification evidence package or offline ledger. Specifically, it performs conflict reloading on all records in the on-site verification evidence package and offline ledger according to conflict reloading rules, offline lease tokens, device status transition diagrams, platform trusted time sequence and risk scores, and generates a status change evaluation result in the form of a reason code. Then, it triggers a handling action based on the status change evaluation result. The local state shadow machine verifies whether the on-site verification data packet meets the state change permission conditions when the network is unavailable, based on the issued offline lease token.

4. The open laboratory equipment management system according to claim 2, characterized in that, The configuration module is also used to count all risk scores within a preset period, and adjust the pass requirements of each rule in the strategy package after the risk score exceeds the set threshold range.

5. The open laboratory equipment management system according to claim 2, characterized in that, The constraint generation module is used to generate a task-evidence-state constraint matrix based on the dynamic context parameters of the device to be managed. Specifically, it binds a set of evidence items and state transition conditions to each step node of the task orchestration information based on the current state of the device, the device's digital passport information, the course plan, the user role, the operation type, and the historical risk score.

6. The open laboratory equipment management system according to claim 1, characterized in that, The task orchestration information in the configuration module includes: operation type, step node set, and prerequisites; the step node set includes: step number, step name, and input field set. The compliance checklist includes at least one of the following categories: mandatory fields, mandatory photo fields, mandatory measurement fields, and mandatory signature fields. The policy package includes: time period rules and / or fence rules, as well as the pass requirements for the rules.

7. The open laboratory equipment management system according to claim 6, characterized in that, The specific steps for the local verification module to perform gate control judgment are as follows: according to the corresponding rules of the policy package, it is determined whether the operation time, the identification information of the device to be managed and the user location information meet the preset requirements. If they meet the requirements, the gate control judgment is passed; otherwise, the gate control judgment is not passed and the corresponding failure reason code is output in the human-computer interaction module. The specific steps for the local verification module to perform compliance verification are as follows: determine whether all items of the compliance checklist have been completed. If not, drive correction and perform multiple security verifications again based on the corrected content. If completed, determine whether the step record satisfies the state transition conditions in the task-evidence-state constraint matrix. If it does, the compliance check is passed; otherwise, the compliance check is not passed, and the corresponding failure reason code is output in the human-computer interaction module. The specific steps for the local verification module to perform evidence sufficiency scoring verification are as follows: First, obtain several sufficiency indicators of the evidence items in the step record, and then fuse them to obtain an evidence sufficiency score. The several sufficiency indicators include at least two of the following: image evidence completeness, measurement data qualification, signature satisfaction, location credibility, device token consistency, or operation time consistency. If the evidence sufficiency score is greater than the state change threshold, the evidence sufficiency score verification is passed; otherwise, it is determined whether the evidence sufficiency score is greater than the correction threshold. If it is greater than the correction threshold, correction is driven, and multiple security verifications are performed again based on the corrected content. If it is less than the correction threshold, the evidence sufficiency score verification is not passed, and the corresponding failure reason code is output in the human-computer interaction module.

8. The open laboratory equipment management system according to claim 1, characterized in that, The configuration module is also used to configure the destination token and disclosure policy; The human-computer interaction module performs field-level minimal collection of step records based on the target token, and generates a hierarchical desensitized view based on the desensitization template of the disclosure strategy for display or uploading. The on-site verification data package generation module performs field-level minimization collection on the on-site verification data package based on the destination token, and generates a hierarchical desensitized view based on the desensitized template of the disclosure strategy for display or uploading.

9. The open laboratory equipment management system according to claim 1, characterized in that, The device management platform also includes an audit module, and the mobile terminal also includes a security module; The audit module is used to package the on-site verification evidence package summary, equipment status change assessment result, status change assessment timestamp, platform signature information and terminal signature verification result into a platform evidence package; The security module is used to construct an audit chain for all records of the on-site verification evidence package or offline ledger, and to receive the platform evidence package; the audit chain includes: the version number of the task-evidence-state constraint matrix, the evidence sufficiency score, and the version of all configuration information corresponding to the current operation type.

10. The open laboratory equipment management system according to claim 1, characterized in that, The device management platform also includes a maintenance module, which is used to update the device's digital passport information after the user completes the operation process for the device to be managed.

Images