A fire-fighting maintenance whole-process digital management method and device and a readable storage medium

Abstract

The application provides a fire protection maintenance whole-process digital management method and device and a readable storage medium, and is applied to the technical field of data processing. Whole-link maintenance data such as equipment account books and personnel qualifications are first collected, and fire compliance operation and maintenance standards are aligned; the system boundary is divided according to the hierarchical design principle, the compliance double threshold is configured, and the six-layer digital architecture is built. Relying on the dispatch middleware, data verification, template reuse and resource recycling integrated management and control are realized, a two-dimensional hierarchical permission system of personnel and equipment is constructed, high-risk businesses are isolated through a container sandbox, and whole-process audit traces are completed. Based on a multi-index weighted scoring model, two types of work order distribution modes are designed, and the dispatch core parameters are solidified; through workflow disassembly, multi-dimensional job data is aggregated, three types of data anomaly disposal mechanisms are matched, combined with the compliance RAG knowledge base and the isolated reasoning sandbox, the dispatch computing power, concurrency and retrieval resources are dynamically and adaptively dispatched, and a fire protection maintenance digital closed-loop system is formed.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method, device, and readable storage medium for digital management of the entire fire protection maintenance process. Background Technology

[0002] Existing digital tools for fire protection maintenance are mostly simple forms, stand-alone software, or basic online platforms, which only realize basic document storage and input, and have not established a standardized end-to-end management and control system. They have multiple levels of core technical defects, as follows: The architecture lacks a six-layer microservice design, resulting in highly coupled modules and a lack of interface decoupling, serial implementation, and end-to-end closed-loop traceability mechanisms, leading to extremely high costs for business iteration and transformation. Compliance verification relies on a single standard, failing to differentiate between ordinary and high-risk points for dual-linkage threshold configuration, and lacks automatic itemized scoring and risk marking logic, making it easy for manual verification to miss high-risk vulnerabilities. Business processes lack event triggers and snapshot caching reuse capabilities, requiring manual reconfiguration of document status and rectification parameters, causing bottlenecks in large-scale business processing.

[0003] The scheduling pipeline lacks integrated capabilities for schema validation, DAG dependency resolution, template caching, and automatic recycling of idle containers. Data validation, process control, and resource release all rely on manual intervention. Access control is coarse-grained, lacking a two-dimensional RBAC matrix for personnel and locations, and three-level operation permissions. High-risk services are not isolated by container network segments. Operation log collection, encrypted backup, and traceability mechanisms are missing, resulting in significant risks of unauthorized tampering and lack of regulatory credentials. Work order distribution is limited to fixed areas, lacking an AHP multi-factor weighted scoring model, and failing to differentiate between automatic allocation and bidding modes. Scheduling parameters are fixed and not dynamically adjustable, making it impossible to dynamically reallocate work orders based on potential risks or personnel load. There is no automatic multi-dimensional data aggregation or three-level intelligent anomaly resolution logic. An isolated RAG compliant inference sandbox is not built, and computing power, concurrency, and retrieval resources cannot adaptively smooth out peaks, causing inference operations to crowd out basic business resources.

[0004] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part by practice of the invention.

[0006] According to one aspect of this application, a digital management method for the entire fire protection maintenance process is provided, including: acquiring fire equipment ledgers, maintenance locations, and personnel qualification data, covering the entire business chain of inspection, maintenance, rectification, and acceptance, and aligning fire protection compliance regulations with on-site operation and maintenance standards; defining system functional boundaries based on the principles of single responsibility, full-chain closed loop, and scalability, setting maintenance compliance dual verification thresholds, establishing standardized business scenario switching rules, and building a six-layer digital fire protection maintenance system architecture; completing integrated scheduling of data verification, business parsing, template reuse, and resource unloading, building a two-dimensional personnel-equipment permission matrix, dividing three levels of operation granularity, and implementing high-risk business isolation and full-process audit traceability mechanisms; constructing routing strategies based on task accuracy, personnel load, hidden dangers, and urgency, and relying on comprehensive scoring thresholds to achieve automatic allocation and Top-K bidding claim dual distribution logic, and solidifying core business priority data; decomposing collaborative sub-tasks according to business complexity, aggregating multi-dimensional operation data, and configuring intelligent resolution and traceability mechanisms for data deviation, verification conflicts, and compliance disputes; and building an intelligent reasoning system based on a compliance knowledge base and business sandbox to achieve adaptive scheduling of system computing power, concurrency, and retrieval parameters.

[0007] Another aspect of this application is a digital management device for the entire fire protection maintenance process, wherein the system is configured to execute the above-described digital management method for the entire fire protection maintenance process by executing the executable instructions.

[0008] According to another aspect of this application, an electronic device includes: a first processor; and a memory for storing executable instructions of the first processor; wherein the first processor is configured to execute the above-described digital management method for the entire fire protection maintenance process by executing the executable instructions.

[0009] According to another aspect of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a second processor, implements the above-described digital management method for the entire fire protection maintenance process.

[0010] The beneficial effects of this application are as follows: By constructing a six-layer serial distributed microservice digital architecture for fire protection maintenance, following the principles of single responsibility, full closed loop, and scalability, six major business domains are divided. A unified pipeline integrating data verification, DAG process parsing, Redis template caching, and idle container recycling is integrated using scheduling middleware. A two-dimensional personnel location permission matrix using RBAC is built, and high-risk operations such as hot work are handled through an independent isolated sandbox, accompanied by six-field encrypted time-series auditing and linkage verification of three types of global control parameters. An AHP four-factor weighted scoring model is adopted, setting a 0.75 score threshold to distinguish between automatic dispatch and Top-K bidding dual-distribution modes. Work order scores are dynamically recalculated through 60-second polling, and scheduling parameters are visualized and adjustable. The front-end workflow engine breaks down collaborative subtasks according to complexity and sets up a three-level resolution mechanism for data deviation, verification conflict, and compliance dispute. The back-end builds a 512-dimensional vector RAG compliance knowledge base, and the isolated inference sandbox is combined with adaptive parameter tuning of three types of indicators: CPU, concurrency, and retrieval time. This forms a complete digital closed loop from data collection, access control, work order scheduling, business processing to intelligent compliance inference, which is suitable for concurrent scenarios of large-scale maintenance of multiple buildings.

[0011] This application employs a layered microservice decoupled module, allowing for the expansion of only local interfaces in new maintenance scenarios without requiring a complete system refactoring, significantly reducing expansion costs. Furthermore, it utilizes dual-threshold linkage for automatic scoring and event-driven snapshot reuse to reduce repetitive manual configuration, standardize compliance assessments, and lower the risk of regulatory penalties. Through dual isolation of network segments and containers for high-risk operations, hierarchical access control, and end-to-end encrypted logging, the risk of unauthorized modification is controllable, incident tracing evidence is complete, and multi-dimensional intelligent work order dispatch is dynamically adjusted to balance personnel load, prioritizing high-risk work orders for specialized personnel, thus improving the timeliness of hazard handling. In addition, by using inference computing power to smooth out peak and trough periods and automatically splitting and aggregating batch documents, it balances throughput performance with intelligent compliance assessment, ensuring stable and smooth system operation during peak periods.

[0012] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0013] Figure 1 This invention provides a flowchart illustrating a digital management method for the entire fire protection maintenance process according to an embodiment of this application. Figure 2 This illustration shows a structural schematic diagram of a digital management device for the entire fire protection maintenance process provided in an embodiment of this application. Detailed Implementation

[0014] The preferred embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.

[0015] In one implementation, Figure 1 A schematic diagram of a digital management method for the entire fire protection maintenance process according to an embodiment of this application is shown.

[0016] S101 acquires data on fire equipment ledgers, maintenance locations, and personnel qualifications, covering the entire business chain of inspection, maintenance, rectification, and acceptance, and aligns with fire safety compliance regulations and on-site operation and maintenance standards.

[0017] In one implementation, the first data acquisition link collects fire equipment records. This acquisition link belongs to the static data acquisition branch of the maintenance-wide data access module. The link is independently allocated bandwidth resources and does not compete for transmission channels with point or personnel acquisition links. The link connects to the local storage partition of the building's fire alarm host, the built-in storage module of the sprinkler control cabinet, and the flash memory unit of the fire hydrant network monitoring terminal. It batch reads five core fields for each device: globally unique hardware code, physical installation floor number, factory rated voltage and flow operating parameters, legally mandated periodic maintenance interval, and mandatory scrapping service life. The data synchronization task starts a full data retrieval task at 2:00 AM every day, with the maximum execution time of a single full synchronization controlled at 45 minutes. Equipment addition, equipment replacement, and equipment removal events trigger incremental data acquisition tasks, with the transmission latency of incremental data from the terminal to the server locked at 2000ms. Taking sprinkler heads and photoelectric smoke detectors as examples, the statutory maintenance cycle for sprinkler heads is fixed at 180 days, and a maintenance pending record is automatically generated upon reaching the cycle node. The mandatory scrapping age for photoelectric smoke detectors is 12 years, and the system automatically calculates the remaining usage time based on the equipment's entry into the warehouse. After data collection, the original data for each equipment ledger is first standardized in terms of field length, and then temporarily stored in a memory buffer queue for unified verification.

[0018] The second data collection link collects maintenance point data. This link runs in parallel with the equipment ledger collection link, using a GIS spatial repository for building fire protection points as the data source. Each read outputs four fields: fire compartment number, point's two-dimensional coordinates, point risk classification identifier, and zone-specific maintenance interval. Risk classification uses only two fixed numerical identifiers: value 1 corresponds to Class I high-risk points like power distribution rooms and hazardous chemical warehouses; value 2 corresponds to Class II regular points like fire hydrants in ordinary corridors and office areas. For high-risk points with value 1, the system automatically applies high-risk operation threshold judgment rules during subsequent compliance verification; for regular points with value 2, it matches general compliance thresholds. Point coordinates are stored in meter-level floating-point format. Each point data entry is pre-bound to the hardware codes of all equipment within the partition, establishing a pre-defined index linking points and equipment, providing a basis for point selection in the subsequent work order distribution module.

[0019] The third link collects personnel qualification data. This link uses a dual-channel approach: offline electronic entry of paper qualification files and online data synchronization with the qualification management platform. It uniformly inputs three core fields: the maintenance personnel's global identity code, the fire protection facility operator's certificate number, and the certificate expiration date. The system has a built-in time warning rule, calculating the difference between the current system time and the certificate expiration time. If the difference is less than or equal to 90 days, a qualification expiration reminder will be continuously pushed. Example of qualification level classification: Level 1 fire protection facility operator certificates have a legal validity period of 6 years, and their qualification permissions cover the operation of all types of fire alarms, sprinklers, and fire hydrants; Level 2 operators can only operate conventional fire hydrants and simple emergency lighting equipment. The collected personnel identity code will serve as the row identifier in the subsequent RBAC two-dimensional permission matrix, directly integrated into the business resource and permission control module.

[0020] After the static three-category data collection process is completed, the dynamic business aggregation link is automatically initiated. This link connects to the on-site mobile work order submission interface. After the submission of four types of business documents—inspection, maintenance, rectification, and acceptance—the interface pushes a message to trigger the aggregation program. The entire data processing time is controlled within 1000ms. The system has built-in association and binding logic, automatically extracting the equipment hardware code and operator identification code from the documents, and matching them with the ledger database and personnel qualification database to complete two-way association index binding. Inspection documents store the equipment appearance and functional power-on test results in text format; maintenance documents fully record the replacement parts model and post-debugging operating parameters; rectification documents fill in the hazard level number and the maximum allowed rectification time limit; acceptance documents store the retest indicators and the final compliance judgment text conclusion. All business documents are uniformly stored in a temporary business data table, awaiting processing by the two-layer alignment and calibration process.

[0021] After all static and dynamic data are collected, a two-layer alignment calibration logic is executed serially. Upon calibration, a standardized dataset is generated and pushed to the six-layer architecture storage layer. The first-layer calibration aligns with national legal standards for the operation and maintenance of fire protection facilities, setting two sets of fixed score thresholds: a general compliance threshold of 80 points and a special threshold of 92 points for high-risk operations. A scoring mechanism is used to determine the compliance of documents. For documents indicating Level 1 high-risk hazards (risk level 1), a strict 72-hour rectification deadline is imposed; exceeding this deadline results in a direct deduction of the corresponding compliance score. When a document's overall score is lower than its matching threshold, a compliance risk marker field is added to the data row. Example: A fire hydrant maintenance document in a stairwell has an overall score of 75, lower than the general threshold of 80, and is marked as having a general compliance risk; a hot work maintenance document in a power distribution room has a score of 90, lower than the high-risk threshold of 92, and is marked as having a high-risk compliance risk.

[0022] The second layer of calibration aligns with the on-site operation and maintenance guidelines for the project implementation, verifying each line of the required standard fields built into the documents. When a document lacks a required field, a null value identifier is added and a record is retained. If there is a conflict between the document's content and the on-site operation guidelines, a separate conflict record is generated, bound to the corresponding document's unique number. These conflict records are simultaneously stored in the audit database for subsequent manual review. After both layers of calibration are completed, all field character formats are standardized, and numerical values ​​retain decimal places, outputting a standardized and complete dataset.

[0023] S102, based on the principles of single responsibility, full-link closed loop, and scalability, defines the functional boundaries of the system, sets dual verification thresholds for maintenance compliance, establishes standardized business scenario switching rules, and builds a six-layer digital system architecture for fire protection maintenance.

[0024] In one implementation, business micro-modules are decomposed based on three architectural design principles: single responsibility, end-to-end closed-loop, and scalability. The functional boundaries of each subsystem are clearly defined according to data, permissions, scheduling, tasks, business, and inference domains, and cross-module coupling is isolated through interface contracts. This decomposition logic is executed independently by modules defined by the layered architecture specification, strictly bound to the three hard constraints of single responsibility, end-to-end closed-loop, and scalability throughout the execution process. These three constraints apply synchronously to the entire process of micro-module division, interface definition, and business iteration. The single responsibility constraint requires that each micro-module only carries one type of exclusive business logic and does not superimpose other unrelated processing logic. The overall system is divided according to six fixed functional dimensions: data domain, permission domain, scheduling domain, task domain, business domain, and inference domain. Each dimension is further divided into several independent micro-modules. Each micro-module has a defined fixed processing boundary, which includes three clearly defined scopes: processable document types, readable and writable data fields, and external interface calls. All business operations outside these scopes are intercepted.

[0025] The end-to-end closed-loop constraint requires that all processing steps of a single maintenance work order, from raw data collection to compliance reasoning and judgment, must sequentially pass through micro-modules corresponding to six dimensions. After each module completes its processing, it sends a complete processing log back upstream via an interface. The log includes three types of information: document number, processing time, and verification result. If any module encounters an error, the upstream module can retrieve the end-to-end log through the interface to locate the fault node. The work order process will not lose data midway, and there are no business interruptions. The scalability constraint requires that all module functions, data storage, and interaction interfaces reserve extended fields. New business needs do not require changes to the original underlying logic; only the interfaces and fields need to be added for adaptation.

[0026] The system uniformly compiles standardized interface contracts for all micro-modules across six dimensions. The contracts specify clear numerical limits for each interaction interface, setting the maximum data capacity for a single interface transmission to 500 document records. The character length of returned fields is uniformly limited, with text fields having a maximum of 200 characters and floating-point values ​​retaining two decimal places. The contracts explicitly prohibit any micro-module from using direct database connection statements to access the storage resources of other modules. All cross-module data reading and data modification operations can only be completed by calling the standardized interfaces registered in the contracts.

[0027] Specifically, the data domain comprises three sub-modules: ledger storage, inspection data, and qualification storage. It only connects to the maintenance-wide data access module to output standardized datasets and provides only two types of registration interfaces: data reading and field schema verification. Channels for work order editing and computing power application are not open. When the task domain retrieves equipment parameters such as a sprinkler head maintenance cycle of 180 days or a smoke detector's 12-year scrapping period, it must call the data domain's read interface; it cannot directly access the underlying ledger data table.

[0028] The permission domain comprises two sub-modules: Permission Loading and Gateway Interception. These modules only receive user request messages from the scheduling domain and output permission matching results; they do not have the authority to modify work order content. When the business domain needs to verify whether a person possesses the required 6-year Level 1 operator qualification, it can only call the permission domain's verification interface.

[0029] The scheduling domain has two sub-modules: resource allocation and Pod unloading. It is only responsible for allocating memory and computing resources. The memory usage threshold of 20% and the idle time threshold of 300 seconds are used as the criteria for resource reclamation. It only issues computing power usage certificates to the inference domain and business domain, and does not have the ability to store data or distribute work orders.

[0030] The task domain has two sub-modules: work order scoring and work order dispatch. They run AHP weighted scoring logic. The comprehensive scoring threshold of 0.75, Top-K value of 5, and bidding time limit of 1800 seconds are all fixed inside the module. It can only call the data domain to read the equipment risk classification value and cannot directly modify the personnel qualification data.

[0031] The business domain includes inspection process micro, rectification process micro, and acceptance process micro, which handles the work order flow across all scenarios. When adding a new category of combustible gas detector maintenance, only one set of input and acceptance interfaces needs to be added to this module. The original code, data tables, and interface contracts of the data domain, permission domain, scheduling domain, task domain, and inference domain remain unchanged. Only a few interaction fields need to be added to complete the business expansion.

[0032] The inference domain comprises two sub-modules: RAG retrieval micro and sandbox computing micro. It can only apply for computing power quotas from the scheduling domain. When the CPU load exceeds 80%, it will automatically apply for a 30% increase in computing power. It has no right to directly write to or modify the work order data table in the business domain. Inference results in compliance disputes can only be returned to the business domain through the relay interface of the scheduling domain.

[0033] The six micro-modules have completely isolated business processing boundaries with no functional overlap. The complete workflow of a single work order is fixed as follows: data domain -- permission domain -- scheduling domain -- task domain -- business domain -- inference domain. Each interface interaction log is synchronously stored in a time-series encrypted library, forming a complete closed loop. When a new high-risk hazardous chemical warehouse maintenance scenario is added, only the corresponding verification interfaces are added to the business domain and inference domain. The original operating logic, data storage structure, and interface contracts of the other modules are all retained. Only the newly added interaction fields need to be adapted, without the need to refactor the entire system, fully meeting the scalability constraints.

[0034] Two sets of judgment standards are configured: a general maintenance compliance threshold and a high-risk operation special verification threshold. These two thresholds are linked to verify the compliance of business documents. The entire compliance score judgment logic is executed by a built-in verification engine within a layered architecture specification definition module. The engine pre-defines two independent score judgment benchmarks, named the general maintenance compliance threshold and the high-risk operation special verification threshold, respectively. These two benchmarks are stored in a distributed configuration center parameter pool and are linked to the risk level values ​​of the locations to trigger rules. When a document enters the verification process, the engine first reads the risk identifier of the maintenance location bound to the document. For ordinary locations with a risk level of 2, the general maintenance compliance threshold of 80 points is used for calculation; for first-level high-risk locations with a risk level of 1, the high-risk operation special verification threshold of 92 points is used for calculation. The two thresholds simultaneously complete the itemized scoring calculation, without executing a single standard judgment separately. The two itemized scoring results are merged to generate a unified document compliance label field, which is then stored in the document master table.

[0035] The general maintenance compliance threshold is 80 points, and the high-risk operation specific threshold is 92 points. An adaptive adjustment formula is used for the general approach. Where k is the scenario correction coefficient: k=+3 for factories, k=-2 for hospitals, and k=0 for office buildings; ΔS is the difference between the total number of equipment in the park and the standard commercial park. The more equipment there is, the higher the high-risk threshold should be, and the lower the threshold should be to adapt to the relaxed regulatory standards for small parks.

[0036] The total score calculation for documents adopts an itemized deduction mechanism. The calculation dimensions include four items: maintenance cycle compliance, personnel qualification matching, hazard rectification time limit, and on-site inspection completeness. Each item has a fixed base score, with base scores of 30, 25, 25, and 20 points respectively. The four scores are added together to obtain the document's maximum score of 100 points. If a single item fails to meet the standard, the corresponding points are deducted. Taking a maintenance document for a common building corridor fire hydrant as an example, this document is bound to a risk classification value of 2 and uses the general maintenance compliance threshold of 80 points for calculation. The maintenance cycle item deducts 0 points, the personnel qualification item deducts 5 points, the hazard rectification item deducts 10 points, and the inspection record item deducts 10 points. The document's overall score is 75 points. Since 75 is less than 80, the document's compliance label is marked as general non-compliant, and the system automatically triggers the document return and re-examination process.

[0037] Taking the hot work maintenance form for the power distribution room as an example, this form is bound to a risk level value of 1. It uses the high-risk operation special verification threshold of 92 points for calculation. The maintenance cycle item deducts 0 points, the personnel special qualification item deducts 3 points, the hidden danger rectification time limit item deducts 4 points, and the hot work special inspection item deducts 3 points. The form's calculation score is 90 points. Since 90 is less than 92, the form's compliance label is simultaneously marked as high-risk compliance risk. In addition to being returned for re-examination, an additional manual review notice is pushed to the corresponding approver.

[0038] The two types of thresholds are calculated synchronously and in parallel throughout the process, ensuring that no single standard is used for judgment. The same document will output two sets of values ​​simultaneously: a general dimension score and a high-risk dimension score, which facilitates the subsequent retrieval of judgment results from different dimensions by business domain and inference domain modules. When a document contains a composite scenario of routine equipment maintenance and high-risk hot work operations, the engine will simultaneously use two sets of thresholds: 80 points and 92 points. If either threshold fails to meet the standard, the entire document will be deemed non-compliant, thus achieving dual-threshold linkage verification.

[0039] All deduction values, two sets of threshold values, and four basic scores are fixed in the configuration center, supporting visual modification and adjustment in the backend. After adjustment, there is no need to restart the verification engine; the next batch of document verification will directly load the updated score parameters, adapting to the needs of different building sites for adjusting the tightness of fire supervision. The generated score details, threshold matching types, and risk markers after verification are all written to the audit database and bound to the document number to retain a complete record, which can be retrieved and traced in subsequent compliance dispute resolution.

[0040] The entire lifecycle of inspection, maintenance, hazard rectification, and final acceptance is streamlined, and standardized scenario switching is driven by business event triggers, with a corresponding snapshot reuse mechanism for scenario parameters. First, the entire lifecycle of four types of documents—inspection, maintenance, hazard rectification, and final acceptance—is fully analyzed. Each type of document is assigned a fixed status identifier: inspection documents include three statuses: pending execution, completed, and hazard detected; maintenance documents include three statuses: pending assignment, under construction, and completed self-inspection; rectification documents include three statuses: pending handling, handling, and reviewing; and acceptance documents include three statuses: pending review, verification passed, and verification rejected. All status change nodes are configured with independent business event triggers, which are linked to the document status field in real-time monitoring. Modification of the document status value triggers the scenario switching logic.

[0041] Each business operation scenario has a built-in fixed set of parameters, which include four categories: location risk level values, compliance verification thresholds, work order time limits, and personnel qualification matching tags. When the scenario starts running, the scheduling unit automatically captures all current parameters to generate a snapshot file. The snapshot is stored in the Redis cache, with a cache retention period of 72 hours and a cache capacity limit of 500 scenario snapshots. If the capacity is exceeded, the earliest generated snapshot will be cleared first.

[0042] The complete execution chain for triggering a document status change is as follows: The database listener captures the document status field update instruction, pushes the change message to the trigger queue, the trigger reads the location risk level value and hidden danger level value bound to the document, matches the corresponding business operating environment, and synchronously captures the currently effective compliance threshold, rectification deadline, and personnel access conditions to generate a snapshot and write it to the cache. When the next document of the same type and level enters the process, the scheduling unit first searches for a matching snapshot in the cache. If the snapshot exists, all parameters are loaded directly, skipping the parameter initialization step.

[0043] Taking the flow of inspection documents as an example, the original status of the inspection document is "completed". The system reads the hazard level value of 3 and the location risk classification value of 1 from the document, and updates the status field to "hazard detected". After receiving the status change message, the trigger automatically switches to the hazard rectification business operation environment. The snapshot is synchronously written to the current high-risk special verification threshold of 92 points, the rectification time limit of 72 hours for level 1 locations, and the corresponding special personnel qualification label parameters. When new inspection documents for level 1 high-risk locations and level 3 major hazards in the same power distribution room are generated in the future, the dispatch unit retrieves the matching snapshot and directly reuses the entire set of parameters without reconfiguring the rectification time limit and compliance judgment standards. The initialization time of a single scenario is reduced from 1200ms to less than 200ms.

[0044] Composite business documents also adapt to snapshot reuse logic. When a document contains both equipment maintenance and hazard rectification business nodes, and its status changes to "pending review," the trigger synchronously caches two sets of parameter snapshots: a general maintenance threshold of 80 points and a rectification time limit. Subsequent similar composite documents can retrieve parameters from both scenarios at once without separate configuration. All snapshot generation, retrieval, and clearing operation logs are synchronously written to a distributed time-series database. The logs are bound to the document number, snapshot generation time, and snapshot parameter details. When compliance disputes or process verification conflicts occur, the business data governance module can retrieve historical snapshots to fully restore the operational constraints at that time, supporting three-level resolution logic for source tracing and judgment.

[0045] The entire scenario switching and snapshot reuse mechanism relies on the six-layer architecture resource scheduling layer to provide cache computing power support. When the memory occupied by snapshot storage reaches 20% of the container memory threshold, the scheduling middleware automatically triggers the reclamation of idle cache Pod resources to release memory space and ensure the stable operation of snapshot read and write in scenarios with multiple batches of concurrent documents.

[0046] The system employs a six-layer technical architecture: storage, permissions, resource scheduling, task distribution, business operations, and intelligent inference. This architecture sequentially completes data schema verification, permission matrix loading, task scheduling engine deployment, business process template configuration, and intelligent inference platform integration, enabling the phased implementation of the complete digital fire protection maintenance system architecture. The entire six-layer technical architecture is unified and implemented by modules defined by the layered architecture specifications. The layer arrangement follows the business flow from data storage to intelligent computing, with a fixed order: storage layer, permissions layer, resource scheduling layer, task distribution layer, business operations layer, and intelligent inference layer. All layers adopt a serial, step-by-step implementation mechanism. Any upper-layer module must wait for all functional items in the lower layer to pass testing and verification, and for verification logs to be free of anomalies, before proceeding to the next stage of deployment. The minimum verification cycle for a single layer is set at 4 hours. Each layer is bound to specific execution content, and the output of each layer serves as a prerequisite for the operation of the upper layer.

[0047] The first layer is the storage layer, which implements the deployment of full-scale structured data schema rules. It includes four independent field constraint templates: ledger, location, personnel, and work order. Templates specify a maximum of 200 characters for text fields and two decimal places for floating-point numbers. This layer unidirectionally receives standardized datasets from the maintenance data access module. A single batch of 500 records can be added to the dataset, which is then encrypted and persistently stored in a time-series format. It also provides two interfaces: standardized data reading and field compliance verification. All upper-layer modules must access basic maintenance data through this layer's interface; direct connections to the underlying storage are prohibited. The storage layer will only issue a trigger signal to initiate the deployment of the permission layer after completing three tests—data entry verification, schema format verification, and encrypted write—without any errors and outputting a log file showing a 100% pass rate.

[0048] The second layer is the permission layer. The execution logic involves fully loading a two-dimensional permission matrix containing personnel account IDs and fire station codes. It utilizes an RBAC (Restricted Access Control) model, pre-configured with three levels of granular operation rules: read-only viewing, form editing, and workflow approval. The gateway permission interceptor synchronously registers the interface. This layer connects to the business resource and permission management modules, matching personnel-station permission determination results in real-time for all business operation requests. Only after the storage layer has completed verification and received the signal will the system read the permission hierarchy parameter pool in the distributed configuration center and import all personnel permission associations in batches. If the storage layer verification reveals abnormal data formats, the permission matrix loading process is paused, awaiting storage layer repair and retesting.

[0049] The third layer is the resource scheduling layer, which implements the deployment of a distributed microservice integrated scheduling engine. It includes built-in DAG dependency resolution logic, Redis cache management logic, and idle Pod reclamation logic. It presets two resource reclamation criteria: 20% memory usage and 300 seconds of idle time. It can dynamically allocate computing power and cache resources to all upper layers. The prerequisites for this layer to start are the completion of the permission layer matrix loading and successful registration of the gateway interception interface. After the scheduling engine starts, it continuously monitors resource usage metrics at each layer, automatically increasing the computing power quota for containers corresponding to inference and work order processing during peak periods.

[0050] The fourth layer is the task distribution layer, which implements the dual-distribution logic configuration for work orders. It incorporates an AHP multi-factor weighted scoring model, fixing eight parameters: a comprehensive scoring threshold of 0.75, a Top-K value of 5, a bidding time limit of 1800 seconds, and a single person's daily order limit. It fully integrates with the maintenance work order intelligent routing and distribution module, differentiating between automatic allocation and bidding-based assignment channels based on the work order's comprehensive score. This layer must wait for the resource scheduling engine to complete the container resource allocation channel before loading the scoring weight parameter pool and enabling the 60-second timed indicator polling logic.

[0051] The fifth layer is the business operation layer, where the implementation involves the batch entry of four standardized business process templates: inspection, maintenance, rectification, and acceptance. It is bound to compliance dual thresholds and a scenario snapshot reuse mechanism, supporting the entire lifecycle of document status transitions and automatic scenario switching. Document status change triggers are simultaneously registered at this layer. A prerequisite is that the work order distribution link in the task distribution layer is debugged; otherwise, the business process templates cannot be bound to the work order receiving channel, and document status change events cannot be triggered.

[0052] The sixth layer is the intelligent inference layer. Its implementation involves integrating the fire safety compliance RAG vector knowledge base and using an independent containerized sandbox to isolate the inference process. It collects real-time monitoring metrics for CPU load, concurrent requests, and sharded retrieval time, and coordinates with the scheduling controller to adaptively adjust computing power, concurrency, and retrieval parameters. This sandbox container can only complete initialization after all five layers have been deployed and validated. Without the intelligent inference base integrated and the sandbox running, the system cannot access compliance clause retrieval, data deviation arbitration, or automatic compliance dispute inference functions.

[0053] For example, regarding hierarchical dependency constraints, after the storage layer completes the data entry verification for ledgers such as the 180-day maintenance cycle of sprinkler heads and the 12-year scrapping period of smoke detectors, and the verification log shows no formatted errors or failed entry records, the system automatically triggers the permission layer to load the permission matrix corresponding to the 6-year qualification of the first-level operator. If the storage layer document fields have excessively long characters or numerical precision that does not conform to the schema specification, and the verification pass rate is less than 100%, then the permission layer and all subsequent layer deployment processes will be blocked. When the intelligent reasoning layer has not completed the deployment of the RAG knowledge base and isolation sandbox, when the business operation layer encounters a power distribution room hot work dispute document with a score of 90 that is lower than the high-risk threshold of 92, it can only push a manual review notification and cannot automatically call the knowledge base clauses to carry out intelligent reasoning to resolve the issue.

[0054] The entire process of deployment, verification, and startup at each level generates time-series audit logs, which are synchronously written to a distributed encrypted time-series library. Log fields include the level name, verification start and end times, number of abnormal records, and verification pass rate. These complete layer-by-layer logs can be retrieved for traceability during subsequent architecture iterations and fault investigations. This serial deployment mechanism prevents upper-layer business logic from malfunctioning due to incomplete lower-layer data, resources, or permissions, ensuring complete bottom-up linkage of the six-layer technical system.

[0055] S103 integrates data verification, business parsing, template reuse, and resource unloading scheduling; establishes a two-dimensional permission matrix for personnel and equipment; divides operations into three levels of granularity; and implements a high-risk business isolation and full-process audit and traceability mechanism.

[0056] In one implementation, an integrated scheduling pipeline is built upon a distributed microservice scheduling middleware. It incorporates a built-in structured data schema validation rule engine to parse the field specifications of maintenance ledgers and inspection records. It uses a Directed Acyclic Graph (DAG) to resolve upstream and downstream dependencies, employs Redis caching to cache standardized business templates for reuse and acceleration, and triggers the dynamic unloading of idle Pods based on container resource monitoring metrics, periodically releasing memory and computing resources. The integrated scheduling pipeline is mounted on a dedicated microservice instance within the third layer (resource scheduling layer) of a six-layer architecture. The pipeline's underlying layer connects to the distributed microservice scheduling middleware via standardized interfaces, uniformly handling three types of business flow instructions: standardized datasets output from the storage layer, work orders issued from the task layer, and operation requests submitted from the business layer. Internally, the pipeline consists of four independent processing units connected in a fixed serial order: data validation, dependency resolution, template reading, and resource reclamation. Downstream units will not start computation until any upstream unit has completed its processing. Units only exchange structured messages through contract interfaces; there is no direct sharing of memory data.

[0057] The structured data schema validation engine has two built-in independent field constraint templates for ledgers and inspections. Both templates are loaded synchronously into the engine's memory and run resident. The ledger template sets fixed value range constraints for numerical fields; for example, the sprinkler head maintenance cycle field only allows values ​​between 0 and 180 days, and the photoelectric smoke detector scrapping year field is limited to integers between 0 and 12 years. The inspection record template sets length limits for text fields; the maximum number of characters for hazard descriptions and equipment inspection conclusions is 200. Content exceeding this length is truncated and marked as excessively long. After external raw ledgers and inspection documents flow into the pipeline, the engine iterates through each field and compares it against the constraint standards. Data in four categories—excessive values, excessively long text, missing fields, and incorrect data types—are all marked as abnormal and automatically routed to an independent abnormal buffer queue. The buffer queue can cache a maximum of 500 abnormal documents per batch. When the queue overflows, it triggers a persistent write to the time-series database backup without blocking the normal document processing chain. The example imports a ledger document containing a 200-day maintenance cycle for sprinkler heads. The engine identifies the value as exceeding the 180-day range, marks the compliant field as abnormal, and transfers it to a buffer queue to await manual correction before it re-enters the pipeline.

[0058] The Directed Acyclic Graph (DAG) parsing unit reads the full business node association configuration bound to each work order. Using collection, verification, construction, recording, and acceptance as basic nodes, it decomposes upstream and downstream dependency links to construct a unidirectional acyclic association topology. Only after the current node's status flag is completed can a subsequent node be processed. The unit has built-in node blocking logic; work orders that do not meet their preceding dependencies are frozen at the current processing node, and status monitoring messages are continuously pushed to the scheduling gateway. Taking a hot work order as an example, the point qualification verification node within the DAG topology is the only preceding procedure for the on-site inspection node. If the qualification verification node returns a result indicating that the personnel qualification failed, the inspection node directly suspends scheduling and allocation until the personnel qualification information is corrected and the preceding node verification is re-completed. The unit synchronously outputs node dependency relationship logs and writes them to the audit database. The logs are bound to the document number and node blocking duration for business process traceability.

[0059] The Redis caching unit is specifically designed to store standardized business process templates for inspection and maintenance. Template data is written to the cache with a 72-hour expiration policy; if the template data is not accessed within the expiration period, it is automatically evicted and the cache space is released. When the system initiates a new work order, the scheduling pipeline prioritizes sending a template read request to the caching unit. If the cache hits, the entire set of process node configurations is retrieved directly, without needing to fetch the original template data from the storage layer again; only if the cache misses is a persistent layer query triggered, and the cache is updated synchronously. In actual testing, the complete initialization time for a single work order without caching was 1100 milliseconds; after reading the cached template, the initialization time was reduced to 180 milliseconds. In peak scenarios with thousands of concurrent work orders, the overall processing throughput improved by 65%. The cache can simultaneously store up to 500 sets of maintenance process templates from different locations.

[0060] The container resource reclamation unit collects two monitoring metrics in real time: the percentage of memory usage and the duration of continuous idle time for all Pod instances in the cluster. When both metrics simultaneously meet the dual thresholds of memory usage below 20% and continuous idle time exceeding 300 seconds, a container destruction and reclamation command is triggered. After the reclamation command is sent to the middleware, the computing cores and running memory allocated to the container are released synchronously, and the reclaimed resources are automatically allocated to the business Pods corresponding to newly received work orders. During off-peak maintenance hours at night, when there are no on-site work order submissions, the number of idle Pods that can be reclaimed in a single cluster scan is between 8 and 12. After reclamation, resource release records are output and stored in the scheduling log. If the container memory usage is higher than 20%, it remains running even if the idle time exceeds 300 seconds, avoiding network transmission losses caused by frequent container start-stop operations. The reclamation logic is linked with the upper-layer task distribution layer; during peak work order concurrency, the idle threshold is automatically increased to 600 seconds to reduce frequent container destruction and reconstruction operations.

[0061] After the four types of units of the entire pipeline are processed, a standard work order flow message is output, which verifies compliance, ensures the integrity of the dependency link, and confirms that the resource allocation is ready. This message is then pushed to the downstream task distribution layer. The message includes field verification results, cache hit flags, and container resource allocation numbers, which serve as the basic input data for work order scoring and personnel matching. All runtime sequence records of the pipeline are synchronously written to a distributed encrypted time-series database to support the subsequent process of tracing and resolving business anomalies such as data deviations and compliance disputes.

[0062] A two-dimensional permission matrix of personnel account ID and fire equipment location code is constructed, and an RBAC permission control model is configured. Three levels of operation granularity are defined: read-only viewing, form editing, and workflow approval. A gateway permission interceptor is connected to perform real-time parsing of request identity and equipment permissions for matching and verification, supplementing concurrent conflict and timeout circuit breaker rules: if more than 5 operation requests from the same account within 1 second are considered concurrent impacts, automatic queuing and flow limiting are implemented; if permission matching times out three times consecutively, the account is directly circuit-broken for 1 minute, during which all operation requests are blocked, and the permission verification link is automatically restored after the circuit breaker ends; when multiple work orders operate on the same high-risk location simultaneously, they are executed sequentially from highest to lowest hazard level, with lower-level work orders queuing. The permission matrix is ​​deployed within a dedicated microservice instance in the second layer (permission layer) of a six-layer architecture. The overall storage structure adopts a two-dimensional mapping structure, with rows bound to globally unique personnel account IDs and columns bound to globally unique fire equipment location codes. Each intersecting cell in the matrix stores the numerical value of the personnel's operation permission for the corresponding location. The underlying layer fully implements a standard RBAC three-layer hierarchical control model. The three layers, from top to bottom, are the user layer, role layer, and function permission layer, forming a one-way binding association. Users can only belong to one or more roles, and each role is bound to a set of fixed operation permissions in batches. Permissions cannot be directly assigned to personnel; they must be mapped through roles.

[0063] The system pre-defines permission identifiers corresponding to three levels of operation granularity: Level 1 (read-only viewing) is identified by identifier 1, Level 2 (form editing) by identifier 2, and Level 3 (process approval) by identifier 3. Each identifier corresponds to an independent function access scope. Level 1 read-only viewing only opens read-only browsing interfaces for all types of documents (inspection, maintenance, rectification, and acceptance), blocking all form entry, modification, submission, and rejection operations, and preventing the writing of any business data. Level 2 form editing only opens channels for modifying basic fields such as inspection records, maintenance parts replacement, and equipment testing values, locking approval operation interfaces such as acceptance conclusions, compliance judgments, and work order rejections. Level 3 process approval fully opens interfaces for the entire process of document rejection, compliance score modification, high-risk work order review, and acceptance result confirmation, covering all business control actions.

[0064] The gateway permission interceptor is deployed serially in the front-end link of all business request entry points. When any mobile terminal, backend page, or third-party system initiates an operation request, the request message header is required to include two identification fields: the operator's account ID and the target fire point code. After receiving the message, the interceptor simultaneously initiates a matrix retrieval request to the configuration center. The retrieval time limit is 500ms. If the timeout occurs, the permission verification is directly judged as failed and the entire request is intercepted. Taking the modification operation of the hot work acceptance document in the power distribution room as an example, the matrix cell corresponding to the power distribution room point code stores the permission value 2. The operator's account matching only has a second-level editing granularity. After the interceptor retrieves the matrix, it finds that there is no approval operation binding relationship at the current granularity, directly terminates the request and transfers it to the downstream business operation layer, and at the same time returns a permission insufficient prompt message to the calling terminal; if the operator's account is identified as having a 3 in the matrix cell corresponding to the point, the retrieval and matching are successful, and the request is normally allowed to proceed to the business processing link.

[0065] All personnel-location and role-permission association mapping data are uniformly and persistently stored in the distributed configuration center parameter pool. The configuration center provides a visual interface for adding and editing row and column mapping relationships. When adding maintenance locations such as hazardous chemical warehouses and underground parking garages to a project, only the corresponding column location code is added in the matrix and the corresponding permission value is bound. Newly hired Level 1, Level 2, and Level 3 maintenance personnel only need to add matrix row account IDs and configure permission identifiers for each location separately. The entire RBAC permission system and the underlying storage structure of the two-dimensional matrix do not need to be reconstructed or the permission layer microservices need to be restarted. New mapping parameters take effect in real time.

[0066] Each retrieval, addition, and modification operation of the permission matrix generates an independent audit log and writes it to a distributed time-series encrypted library. The log includes the operation account, change point code, new and old permission identifier values, and operation timestamp. In subsequent verification conflict and compliance dispute resolution stages, the complete permission change record can be retrieved to complete the full-link traceability. At the same time, the permission layer operation log is synchronously pushed to the scheduling engine, and the sandbox high-risk operation review and control logic works in synergy.

[0067] High-risk maintenance processes involving hot work and pressure testing are isolated using independent container sandboxes. A cross-service data access whitelist is configured to block unauthorized data read / write operations. Full logs of operator, terminal IP, operation time, modified fields, business document number, and device number are collected synchronously and written to a distributed time-series database with tamper-proof encrypted storage. The high-risk business isolation system consists of two completely independent container clusters: an isolation sandbox container cluster and a general business container cluster. These two clusters are deployed on different physical server nodes, allocated independent virtual network segments, and do not have inter-network routing policies. Only a one-way read-only gateway is configured for limited data interaction; there is no bidirectional data path. Resource allocation standards differentiate between the two clusters. Each running container within the isolation sandbox is allocated a minimum of 2 CPU cores and 4GB of RAM, while the general business container is uniformly allocated 1 CPU core and 2GB of RAM by default. The system load balancer will not schedule routine inspection and ledger calculation tasks to the sandbox cluster, and the sandbox cluster cannot proactively issue business operation instructions to the general cluster.

[0068] The isolated sandbox cluster only handles two high-risk maintenance calculation processes: hot work parameter verification and fire pipeline pressure threshold calculation. Routine business logic, such as inspection information entry, equipment ledger query, general fire hydrant maintenance process calculation, and personnel basic qualification verification, is deployed entirely on the general business container cluster. With the two types of clusters physically isolated, even if an abnormal overflow occurs within the sandbox process, it cannot directly access or tamper with the general cluster's memory and database files, thus isolating the risk of business contamination at the underlying network level.

[0069] The scheduling middleware has a built-in global cross-service access control rule table. This table distinguishes between read-only and write interfaces, forming a fixed access whitelist mechanism. The whitelist only includes basic equipment ledger query interfaces and read-only access interfaces for special personnel qualifications. All other write interfaces, such as those for adding documents, modifying acceptance conclusions, updating hazard records, and changing maintenance status, are permanently blacklisted. When the sandbox cluster initiates any data request, the front-end gateway interceptor synchronously verifies the interface identifier and operation type. Write requests are discarded without forwarding to the main business database; only read-only data packets from the whitelist are allowed.

[0070] Taking the sandbox operation process of hot work in the power distribution room as an example, the sandbox can normally retrieve the risk level value of 1 for the location and the read-only ledger information such as the 6-year validity period of the corresponding first-level operator's qualification. If the sandbox process initiates an update request for the acceptance compliance conclusion field, the gateway recognizes the operation as a write action, directly intercepts and discards the request message, and will not send any modification instructions to the business master database throughout the process, completely blocking the operation path of unauthorized tampering with documents.

[0071] The log collection component is mounted on the front-end link of the traffic entry point of all containers in the sandbox cluster. Any field adjustment, value recalculation, or parameter matching action within the sandbox will trigger the log capture logic in real time. The component forcibly collects six types of fixed mandatory fields, with no default or omitted fields. The six types of fields are: the operator's globally unique account code, the operator's public IP address, the operation timestamp accurate to milliseconds, the full name of the changed business field, the unique number of the document bound to the current operation, and the fire point code corresponding to the operation. The raw log messages collected do not pass through the sandbox or the general cluster business memory cache. They are directly pushed to the distributed time-series database write link through an independent dedicated transmission channel. The entire storage and transmission process uses an asymmetric encryption algorithm to encrypt the complete message. The time-series database has a permanent write protection mechanism enabled at the bottom layer. The database only provides a log read interface and does not provide any operation interface for deleting, overwriting, modifying, or altering logs. After the log is persistently written, the original message cannot be manually deleted or tampered with, thus solidifying the complete original operation record.

[0072] The smallest storage unit of a single high-risk operation log must completely contain all six types of collected fields; the system will not accept logs with missing fields. Taking the modification of the hot work acceptance score in the power distribution room as an example, a complete storage log will fully record the account of the maintenance personnel, the mobile terminal's external IP address, the precise millisecond operation time, the changed acceptance compliance score field, the power distribution room hot work document number, and the first-level high-risk location code. When compliance disputes or verification conflicts arise, auditors can retrieve this log to completely identify the executor, the terminal used, the precise time of the operation, the changed business content, and the high-risk location, fully reconstructing the entire operation process and fully meeting the fire safety supervision requirements for full traceability and control of operations.

[0073] All encrypted time-series logs generated by the sandbox are backed up off-site in conjunction with the system's global control parameters. Audit logs are backed up off-site every 30 days. Every 30 days, the scheduler automatically pulls the full set of sandbox time-series logs and synchronizes them to an off-site independent storage server. After synchronization, a hash checksum for each log entry is automatically generated. The hash values ​​are compared bidirectionally between the local logs and the off-site backup logs to confirm that no data has been lost or tampered with before the backup is considered complete. Simultaneously, each sandbox operation log is associated with and bound to the access control layer gateway verification record and the scheduling layer container resource allocation record. When retrieving logs, the system can simultaneously query the personnel access control matching results and the computing power and memory parameters allocated to the sandbox, forming a complete end-to-end traceability chain of "personnel access control - container resources - high-risk operations - log evidence storage." This supports subsequent data deviation and compliance dispute resolution logic for source tracing and determination.

[0074] Three types of control parameters are configured: permission matching timeout threshold, mandatory manual review switch for high-risk operations, and off-site backup cycle for audit logs. These parameters work in conjunction with the scheduling engine, permission gateway, sandbox container, and log storage components to achieve fully automated verification of resource scheduling, permission classification, risk isolation, and operation tracing. The distributed configuration center persistently stores these three types of global control parameters, with all parameter values ​​and status indicators permanently stored. These parameters can be adjusted via a visual interface, and updates are synchronized in real-time to the scheduling engine, permission gateway, sandbox container, and log storage components without requiring any business microservices to be restarted.

[0075] The first type of control parameter is the permission matching timeout threshold, a fixed value of 500 milliseconds. After a user operation request is transmitted to the permission gateway interceptor, the gateway immediately retrieves the user account ID and location code to search the two-dimensional RBAC permission matrix, and the system starts timing. If the entire process from the completion of request message parsing to the matrix matching the corresponding operation granularity takes more than 500 milliseconds, the permission verification process is deemed invalid, the gateway directly discards the entire request message, issues a blocking command to the downstream sandbox and business container, the entire work order process is directly terminated, and a permission timeout exception record is generated and stored in the audit database. If the matching time is less than or equal to 500 milliseconds, the gateway reads the permission identifier value and allows the corresponding business request.

[0076] The second type of control parameter is the high-risk operation mandatory manual review switch, which only includes two status indicators: on and off (Boolean). The switch status is synchronously sent to all isolation sandboxes. When the indicator is on, for high-risk operations such as hot work pressure testing, after the numerical calculation and field modification are completed in the sandbox, the calculation results will not be directly written to the formal acceptance and rectification master data table. The system automatically pushes a review reminder to the operation terminal of the personnel with three-level approval granularity. The data is only allowed to be written after the approval account completes the confirmation operation. When the switch indicator is off, the sandbox calculation results can be directly entered into the database, omitting the manual review step.

[0077] The third type of control parameter is the off-site backup cycle of audit logs, with a fixed duration of 30 calendar days. The system has a built-in timed trigger task that uses the local time-series database log entry time as the timing benchmark. Every 30 days, a full synchronization task is started, which batch transmits all local encrypted operation logs to the off-site independent storage cluster. After the synchronization is completed, a unique synchronization verification hash value and a synchronization completion document are generated. The two records are permanently stored in the local database as backup credentials. The off-site storage cluster only provides a read-only query interface and does not support log modification or deletion operations.

[0078] The scheduling engine, permission gateway, sandbox container, and log storage are four components that form a closed-loop linkage verification link according to a fixed time sequence. The execution order of this link cannot be changed. After a work order is initiated from the mobile terminal or the backend page, the request is first pushed to the resource scheduling engine. The engine reads the risk level value of the location bound to the work order. High-risk work orders with a value of 1 are allocated isolation sandbox container resources, while ordinary work orders with a value of 2 are allocated general business Pod resources. At the same time as the resource allocation instruction is issued, the request is sent in parallel to the permission gateway interceptor to start the permission matching timer. After the gateway completes the permission determination, it outputs a pass / block instruction. The block instruction directly stops all subsequent calculation processes of the entire work order; the pass instruction is issued to the corresponding sandbox or general container. Every field modification and value recalculation operation within the container will trigger the log collection component in real time, collecting six types of required fields and encrypting them to write them to the local time-series database. If the current review switch is on, the business data output from the sandbox enters the temporary buffer table pending review. Buffer data is not included in the formal document archiving. After the approver completes the confirmation operation, the scheduling engine issues an archiving command, and the buffer data is synchronously written to the formal business table. If the review switch is off, the sandbox data is directly archived and written. The log storage component continuously reads newly added log entries from the time-series library. Every 30 days, it automatically performs cross-node synchronous backup at the scheduled node. After synchronization is complete, a synchronization record and hash checksum are generated and stored long-term.

[0079] Taking the complete workflow of a hot work order in a power distribution room as an example, this work order is bound to a risk level of 1. The scheduling engine prioritizes allocating computing resources to the isolation sandbox and simultaneously sends the operation request to the permission gateway to complete matrix matching. In this instance, the time taken to retrieve the personnel account and the corresponding permission for the power distribution room location was 600 milliseconds, exceeding the 500-millisecond timeout threshold. The gateway immediately issued a blocking signal. Upon receiving the signal, the scheduling engine revoked the sandbox resource allocation instruction. The sandbox will not initiate any pressure value or hot work compliance-related calculation processes, and the entire work order is terminated directly. A permission matching timeout exception log is simultaneously generated and stored in the encrypted time-series database. If the permission matching for a similar power distribution room hot work order takes 420 milliseconds, which does not exceed the threshold, the gateway normally allows entry into the sandbox for computation. At this time, the verification switch is on, and the pipeline pressure detection value calculated by the sandbox is only stored in a temporary buffer area and cannot be written to the formal acceptance document. After the maintenance management personnel with a level-three approval account logs into the system and completes the verification and confirmation operation, the scheduling engine triggers the archiving process. The pressure value in the buffer is synchronously updated to the main acceptance table, and a six-field encrypted log of this complete operation is recorded. When the daily time-series logs have accumulated a 30-day cycle, the log component automatically starts a remote synchronization task, transmitting the full log of the hot work operation in the power distribution room to the remote storage node, synchronously verifying the generation and archiving of hash codes, and completely preserving the entire link record of the high-risk work order from initiation, permission verification, sandbox operation, manual review, and remote backup.

[0080] All anomaly records, resource allocation records, review operation records, and log synchronization records generated during the linkage process are associated with the unique work order number. In the event of verification conflicts or compliance disputes, the business data governance module can retrieve the entire set of time-series records and complete the complete business chain tracing based on the three-level resolution logic. The entire linkage logic is compatible with the operating logic of the six-layer architecture resource scheduling layer, permission layer, business operation layer, and intelligent inference layer, and there are no parameter conflicts or component instruction mutual exclusion.

[0081] S104 combines task accuracy, personnel load, potential risks, and urgency to build a routing strategy. Based on a comprehensive scoring threshold, it realizes automatic allocation and Top-K bidding claim dual distribution logic, and solidifies core business priority data.

[0082] In one implementation, a multi-factor weighted task routing scoring model is built by combining four dimensions: task matching accuracy, on-duty personnel load, on-site hazard level, and work order urgency. Fixed weights are assigned to each dimension using the Analytic Hierarchy Process (AHP). ① General formula for index normalization: ① Map the original index to the [0,1] interval to eliminate dimensions; ② AHP consistency test formula: , The convergence threshold CR < 0.1; if this is not met, the dimension weights are iteratively adjusted until convergence occurs. ③ General calculation formula for work order comprehensive score: ,in =0.35、 =0.25、 =0.22、 =0.18, the four weights sum to 1, the original indicators are normalized and then weighted and summed to obtain the work order comprehensive score.

[0083] The multi-factor weighted task routing scoring model is integrated within a dedicated maintenance work order intelligent routing and distribution microservice in the fourth layer (task distribution layer) of a six-layer architecture. This microservice only receives standardized business indicator data forwarded from the resource scheduling layer and does not directly access the original ledger data tables in the storage layer. The model externally establishes two sets of unidirectional data interaction links: an upstream link for indicator input and a downstream link for score output. Both links adhere to a unified interface contract, with a maximum of 500 sets of work order indicator data per message. Text fields are limited to a maximum of 200 characters, and floating-point values ​​are uniformly retained to two decimal places.

[0084] The upstream input link receives four types of standardized raw indicators: raw collected values ​​of task matching accuracy, real-time collected values ​​of on-duty personnel load, raw identifiers of on-site hazard levels, and collected values ​​of work order urgency. All four types of indicators are cleaned and standardized by the integrated scheduling pipeline of the resource scheduling layer before being pushed out, ensuring no missing or out-of-order input. The downstream output link only pushes out a single floating-point format work order comprehensive score. The score result is directly sent to the scheduling gateway for work order triage and determination. The internal calculation process of the model and the intermediate normalized values ​​of each dimension are not exposed externally, but are only stored in the local scoring log for subsequent traceability.

[0085] The model uses the analytic hierarchy process (AHP) to assign weights to the four dimensions. The weight values ​​are fixed in the microservice's local parameter configuration file, eliminating the need for real-time dynamic calculation of weight proportions. The fixed weights for the four dimensions are: task matching accuracy 0.35, on-duty personnel load 0.25, on-site hazard level 0.22, and work order urgency 0.18. The sum of the four weights is 1, satisfying the basic constraints of weighted calculation.

[0086] The system performs a uniform linear normalization conversion of the four types of raw indicators within the 0-1 range, eliminating calculation imbalances caused by different dimensions of personnel waiting for orders, hazard classification, location distance, and work order time limits. Raw indicators are mapped to the 0-1 range according to their corresponding business intervals. The closer an indicator is to the work order handling requirements, the closer its normalized value is to 1; the lower the indicator's fit, the closer its normalized value is to 0. Only after all raw values ​​have been converted can they enter the weighted summation calculation process. The work order comprehensive score calculation formula is as follows: Comprehensive Score = Normalized Task Matching Accuracy × 0.35 + Normalized On-Duty Personnel Load × 0.25 + Normalized On-Site Hazard Level × 0.22 + Normalized Work Order Urgency × 0.18.

[0087] Once a single work order indicator enters the model, the calculation steps are fixed and divided into three steps. The first step is to read the four types of original indicators and complete the 0-1 normalization conversion. The second step is to multiply the normalized value with the corresponding weight to obtain the sub-item score. The third step is to accumulate the four sub-item scores to obtain the final comprehensive score. All calculations are executed serially by the microservice's built-in independent scoring unit. The unit does not share computing resources with other work order distribution logic to avoid concurrent computing conflicts.

[0088] Taking a hot work order in a power distribution room as an example, after pipeline cleaning, the four original indicators of the work order are normalized. After normalization, the task matching accuracy is 0.9, the on-duty personnel load is 0.3, the on-site hazard level is 0.8, and the work order urgency is 0.9. Substituting these into the calculation formula: 0.9 × 0.35 = 0.315; 0.3 × 0.25 = 0.075; 0.8 × 0.22 = 0.176; 0.9 × 0.18 = 0.162. The sum of the four sub-item values ​​is 0.315 + 0.075 + 0.176 + 0.162 = 0.749, resulting in a comprehensive score of 0.749 for the work order.

[0089] The scoring unit records all data from this calculation and writes it to a distributed time-series log. The log is bound to a unique work order number and stores the original indicators, normalized conversion results, scores for the four sub-items, and the final comprehensive score. In the event of work order allocation conflicts or compliance disputes, the business data governance module can retrieve the log to fully reproduce the entire scoring process and support three-level anomaly resolution logic.

[0090] The scoring unit independently occupies a portion of the container's computing power. The container's basic resource configuration is 1 core and 2GB of RAM. During peak periods of work order concurrency, the scheduling engine can automatically increase the computing power supplied to the model by 30%. The model only responds to dynamic indicators pushed through a 60-second timed poll and does not actively pull real-time data on personnel or locations. All indicator updates are uniformly pushed by the integrated scheduling pipeline to ensure the consistency of input data timing.

[0091] The comprehensive score output by the model is directly used as the basis for the scheduling gateway to distinguish between two types of work orders: automatic allocation and Top-K bidding. The time-series logs generated by the scoring are synchronously written to the full-link audit library and stored in association with permission verification and sandbox operation logs. This fully connects the entire business link of data access, permission verification, resource scheduling, work order scoring, and business flow, and maintains consistency with the overall operating logic of the six-layer architecture.

[0092] The system allows for the configuration of a configurable comprehensive scoring threshold to divide work orders into two categories. Regular work orders with scores below the threshold are automatically assigned based on personnel qualification tags, geographical distance to the work location, and current pending workload, with the scheduling engine issuing work orders in batches. High-priority work orders with scores above the threshold utilize a Top-K bidding mechanism, selecting K personnel with corresponding special operation qualifications to submit work orders to a bidding window. Bidding time limits and daily order limits for each person are set. A threshold judgment logic is established between the scoring model output port and the scheduling gateway. The system uses 0.75 as the comprehensive scoring cutoff value. After a work order is weighted and a floating-point total score is output, the judgment unit compares the score with 0.75. Based on the comparison result, it switches between the two sets of work order distribution execution links. The judgment logic synchronously updates the distribution markers of all unfinished work orders every 60-second periodic polling.

[0093] When the weighted composite score of a work order is less than 0.75, the scheduling engine initiates a batch automatic matching logic. The matching operation simultaneously reads three sets of static and dynamic filtering criteria: personnel skill classification tags, the straight-line distance to the work order location, and the total number of pending work orders for the personnel that day. These three conditions are used simultaneously to select the optimal personnel, and the manual bidding interaction channel is not open. The matching logic execution priority is: qualification matching first, location distance second, and pending order load third. First, personnel without the corresponding equipment operation qualifications are filtered out. Then, from the remaining personnel, those with a straight-line distance to the location less than 1000 meters are selected. Finally, personnel with 4 or more pending work orders that day are removed. The remaining personnel are then batch-sent work order allocation messages, and the system automatically locks the optimal matching personnel to complete the assignment. For example, a typical fire hydrant maintenance work order has a weighted composite score of 0.62, which is less than 0.75. The system first filters out personnel without fire hydrant operation qualifications, then selects on-duty maintenance personnel with a location less than 1000 meters away and fewer than 4 pending work orders that day, and issues allocation notices in batches. There is no personnel bidding operation throughout the process.

[0094] When the weighted composite score of a work order is greater than or equal to 0.75, the system activates a bidding distribution link with a preset fixed parameter K=5. The scheduling engine executes a three-layer filtering logic. The first layer filters all on-duty personnel holding the special operation qualification corresponding to the work order; the second layer sorts them from highest to lowest according to the task matching normalization value; the third layer selects the top 5 personnel and opens an independent bidding interaction window. The link has two built-in fixed constraint parameters: the effective duration of the bidding window is fixed at 1800 seconds, and the daily work order receiving limit for each maintenance personnel is fixed at 8 orders. Once the limit is reached, the personnel are automatically removed from the bidding candidate list.

[0095] For example, a hot work order for a power distribution room has a weighted average score of 0.749, which is below the 0.75 threshold. Therefore, it directly enters the automatic allocation process, matching only personnel with hot work qualifications, meeting the distance requirements to the work site, and having sufficient pending orders for batch dispatch, without opening a bidding window. For example, a hot work order for a hazardous chemical warehouse with a level-three hazard has a weighted average score of 0.81, exceeding 0.75. The system filters all on-duty personnel with high-voltage hot work qualifications, sorts them by matching degree, and sends bidding reminders to the top 5. If 3 of these 5 personnel have already reached the daily limit of 8 orders, they are automatically removed, and the next qualified personnel are added to fill the candidate list. If no personnel confirm receipt within 1800 seconds, the scheduling engine clears the candidate list, re-executes the qualification personnel screening operation, and initiates bidding again.

[0096] The switching records of the two distribution processes, personnel screening details, and bidding timeliness logs are all uniformly written to the distributed time-series audit database. Each record is bound to a unique work order number, which can form a complete traceability chain with the pre-scoring indicators and normalized values. When the risk level or the number of pending orders for personnel changes within the polling cycle, and the recalculated score of the work order crosses the 0.75 threshold, the scheduling engine immediately cancels the original allocation or bidding push message, clears the original candidate list, and re-executes the screening logic according to the new score matching the corresponding distribution link to avoid duplicate push conflicts. The entire threshold determination and personnel screening logic are bidirectionally connected with the task distribution layer microservice, the upstream multi-factor weighted scoring model, and the resource scheduling layer polling interface. All screening values, thresholds, K-values, and timeliness parameters are uniformly stored in the distributed configuration center, which can be adjusted in the backend visual interface. After the parameters are modified, they automatically take effect in the next 60-second polling round without restarting the work order distribution microservice.

[0097] Core business priority data, including personnel skill classification tags, equipment hazard risk levels, work order time limit weights, and scoring weights for each dimension, are persistently stored in a distributed configuration center. This solidifies the basic routing parameter pool and supports dynamic, visual adjustment of weights and iterative distribution strategies in the backend. All priority configuration data related to global routing is uniformly and persistently stored in the distributed configuration center. All parameters are aggregated into an independent global routing parameter pool, which is internally divided into four fixed storage partitions. These partitions correspond to personnel skill classification identifiers, location hazard level values, work order time limit deduction weights, and AHP four-dimensional scoring weight data, respectively. The four data partitions are isolated from each other, allowing for independent read and write operations without interference.

[0098] The personnel skill classification and identification partition stores text tags and matching coefficients corresponding to all maintenance jobs such as fire hydrants, sprinklers, high-pressure hot work, and smoke detectors; the location hazard classification numerical partition stores two classification benchmarks: Value 1 (Level 1 High Risk) and Value 2 (Regular Location); the work order deadline deduction weight partition stores the deduction ratios corresponding to overdue and near-delay work orders; the AHP four-dimensional scoring weight partition stores the original values ​​of four weights: task matching accuracy (0.35), on-duty personnel load (0.25), on-site hazard level (0.22), and work order urgency (0.18). The data of the four partitions are persistently stored on disk, and the parameters will not be lost after the system restarts.

[0099] The distributed configuration center features a visual web interface divided into three main functional areas: a parameter viewing area, a value editing area, and a real-time synchronization status area. After completing permission verification, the operations and maintenance account can directly modify any weight or tier value in the editing area. Clicking the confirmation button after modification triggers the synchronization command. The synchronization link directly connects to the multi-factor weighted scoring model calculation unit within the task distribution layer. The entire process does not require stopping or restarting the task distribution layer microservice process, nor does it require repackaging or deploying the program. After synchronization, a 60-second scheduled polling logic is implemented. The next round of work order metric retrieval and score recalculation directly loads the updated parameters for calculation, automatically overwriting the old weight values.

[0100] The entire set of parameters is updated in conjunction with the original work order comprehensive score calculation formula. The calculation formula is: Comprehensive score = Normalized task matching accuracy × corresponding weight + Normalized on-duty personnel load × corresponding weight + Normalized on-site hazard level × corresponding weight + Normalized work order urgency × corresponding weight. After the weight values ​​are changed, the latest values ​​from the configuration center are directly read during the formula calculation to participate in the multiplication and accumulation operation.

[0101] For example, in typical commercial complexes, there are numerous hazardous chemical storage rooms and power distribution rooms, resulting in a high frequency of Level 3 major hazard work orders. The original hazard level weight of 0.22 is insufficient to lower the score of high-risk work orders. Maintenance personnel log into the visual backend, locate the AHP hazard level weight editing input box, change the original 0.22 to 0.28, and submit confirmation. After submission, the configuration center sends a synchronization message to the scoring unit, with synchronization time not exceeding 300 milliseconds. In the next round of 60-second periodic polling for work order recalculation, all pending hazard work orders will uniformly use a hazard weight of 0.28 in the calculation formula. Taking a set of indicators with unchanged normalized values ​​as an example: task matching accuracy 0.9, on-duty personnel load 0.3, hazard level 0.8, and work order urgency 0.9, the comprehensive score before weight adjustment is 0.9×0.35+0.3×0.25+0.8×0.22+0.9×0.18=0.749; after weight adjustment, the comprehensive score is 0.9×0.35+0.3×0.25+0.8×0.28+0.9×0.18=0.797, with the score increasing synchronously. The work order score of 0.797 exceeds the critical threshold of 0.75, and automatically switches to the Top-K bidding distribution link to realize work order matching and bidding rules automatically iterating with parameters.

[0102] The entire parameter synchronization process generates configuration change logs and stores them in a time-series audit database. The logs record the modified account, the value before modification, the value after modification, and the synchronization completion timestamp. When tracing the source of subsequent work order allocation conflicts and compliance disputes, the corresponding time period weight parameters can be retrieved to fully reproduce the scoring results at that time. It is fully compatible with the operation logic of the six-layer architecture task distribution layer and resource scheduling layer.

[0103] The timed polling logic is embedded within the intelligent routing and distribution microservice for maintenance work orders in the task distribution layer. The trigger interval for the polling interface is fixed at 60 seconds. A long-term bidirectional communication link is established between the interface and the standardized read interfaces of the permission layer and data domain. This link uses a long-connection keep-alive mechanism, and a single data packet can carry a maximum of 1000 dynamic indicators for work orders. Floating-point values ​​within the packet are uniformly retained to two decimal places, and text fields are no longer than 200 characters. At the start of each polling cycle, the interface synchronously pulls three types of dynamic indicators: the real-time pending workload of on-duty personnel, the progress of current work order hazard handling, and the remaining validity period of the work order. These three types of indicators are periodically changing dynamic data and cannot be statically read in a single session; continuous synchronization of the latest status is necessary through polling. Periodically recalculate the comprehensive score of work orders, drive the scheduling gateway to switch between automatic allocation and bidding distribution processes, and update the adaptation rules of existing work orders by configuring parameters: after the AHP weight and scoring threshold are modified in the background, the next round of 60-second polling will uniformly recalculate the score of all unfinished existing work orders. If the score of an existing work order crosses the threshold, the distribution mode will be automatically switched. Completed archived work orders will not be recalculated, reducing the ineffective consumption of computing power.

[0104] After the polling interface retrieves the three types of updated indicators corresponding to all incomplete work orders, it automatically pushes the indicators to the multi-factor weighted task routing scoring model. The model reuses the predetermined calculation formula to recalculate the scores of all work orders. The calculation formula is: Comprehensive Score = Normalized Task Accuracy × 0.35 + Normalized On-Duty Personnel Load × 0.25 + Normalized Hazard Level × 0.22 + Normalized Work Order Urgency × 0.18. The recalculation process is executed serially, calculating each work order one by one according to its unique number. The original work order distribution process is not interrupted during the calculation. The temporary scores generated by the recalculation are stored in the memory buffer. After all work orders are recalculated, they are uniformly synchronized to the scheduling gateway score storage area.

[0105] The scheduling gateway has a built-in threshold comparison and judgment unit that uses 0.75 as a fixed threshold to compare the comprehensive score of each work order after the update. If the score before and after the work order update is either below 0.75 or greater than or equal to 0.75, it is determined that the score has crossed the threshold. The gateway immediately issues a process termination command, cancels the currently executing automatic allocation push or bidding window, clears the original candidate list, and matches the corresponding distribution logic according to the new comprehensive score.

[0106] The system persistently stores all data from each round of queries and each work order, writing it to a distributed encrypted time-series database. A single work order's complete log contains five types of raw information: four raw data collection indicators—task matching accuracy, on-duty personnel load, hazard level, and work order urgency; normalized values ​​for each dimension after conversion from 0 to 1; a weighted total score calculated using formulas; a list of qualified personnel selected by the system; and records of interactions such as confirmation and timeout abandonment by bidding personnel. The time-series database is write-protected, meaning logs cannot be deleted or modified after being written. In case of work order allocation conflicts or compliance disputes, the business data governance module can retrieve the complete set of indicators and scoring records for the corresponding time period using the work order number, fully reproducing the work order dispatch logic at that time.

[0107] For example, for an initial level 3 hazard maintenance work order, the hazard level normalized value retrieved in the first round of query is 0.6. The other normalized indicators are task matching accuracy 0.9, on-duty personnel load 0.3, and work order urgency 0.9. Substituting these into the formula, the comprehensive score is calculated as 0.9×0.35+0.3×0.25+0.6×0.22+0.9×0.18=0.705. Since the score of 0.705 is less than 0.75, the system automatically assigns personnel in batches and issues notifications to qualified maintenance personnel. In the next 60-second polling cycle, the hazard handling progress indicator is updated. The normalized value corresponding to the hazard upgrade is increased to 0.8, while the other indicators remain unchanged. The score is recalculated as 0.9×0.35+0.3×0.25+0.8×0.22+0.9×0.18=0.749, which still does not cross the threshold, so automatic allocation continues. In the third polling cycle, the hazard level normalized value is updated to 0.85, and the recalculated score is 0.9×0.35+0.3×0.25+0.85×0.22+0.9×0.18=0.76. The score of 0.76 is greater than 0.75. The scheduling gateway recognizes that the score has crossed the critical threshold, automatically cancels the previously issued allocation notification, and selects the top 5 on-duty personnel with the corresponding special operation qualifications to open the bidding interaction window. All data from this indicator update, score recalculation, and process switch are synchronously generated into a complete log, bound to the work order number, and archived in an encrypted time-series database. The entire work order's time-sharing scoring record can be retrieved at any time to complete the traceability.

[0108] S105 breaks down collaborative sub-tasks according to business complexity, aggregates multi-dimensional operational data, and configures intelligent resolution and traceability mechanisms for data deviation, verification conflicts, and compliance disputes; it builds an intelligent reasoning system based on a compliance knowledge base and a business sandbox to achieve adaptive scheduling of system computing power, concurrency, and retrieval parameters.

[0109] In one implementation, routine maintenance work orders rely on a visual workflow engine to analyze business complexity thresholds and automatically break down cross-position collaborative sub-tasks. Through a unified data middleware layer, standardized cleaning of equipment ledgers, personnel qualifications, and inspection / rectification multi-source fields completes the structured aggregation of multi-dimensional operational data, adapting to scenarios involving batch processing of large volumes of standardized maintenance documents. This processing flow is deployed within a dedicated visual workflow engine at the six-layer architecture business operation layer. The workflow engine upstream connects to the standardized dataset output by the integrated scheduling pipeline, and downstream pushes aggregated structured data to the compliance knowledge base of the intelligent inference layer. The engine establishes a one-way data flow channel with the data middleware layer, only receiving the cleaned ledger, personnel, and inspection multi-source data, without directly reading the original collection messages. The engine has a built-in fixed business complexity judgment benchmark; the system presets a value of 0.6 as the splitting threshold. When the overall complexity value of a work order is higher than 0.6, it is automatically broken down into independent multi-position collaborative sub-tasks; when the value is lower than 0.6, the single task remains intact. The unified data middleware layer incorporates standardized cleaning rules for multi-source fields, unifying text length, numerical precision, and field naming conventions. It performs unified mapping and standardization on heterogeneous fields such as equipment maintenance cycle, personnel qualification validity period, and hazard level, completing the aggregation of multi-dimensional operation information and generating a unified format structured work order dataset, which is suitable for business scenarios involving the batch parallel processing of thousands of standardized inspection and maintenance documents per day.

[0110] For example, a maintenance work order for the entire building of a large shopping mall, covering multiple types of equipment such as sprinklers, smoke detectors, and fire hydrants, yielded a business complexity of 0.72 after work order parsing, exceeding the 0.6 splitting threshold. The engine automatically split it into three sub-tasks: equipment appearance inspection, parts replacement, and pressure retesting. These three sub-tasks were then assigned to different personnel. A single fire hydrant work order for a single corridor had a complexity of 0.45 and was not split, allowing a single person to complete the entire process. Both types of work orders underwent data cleaning at the intermediate layer. Different types of values, such as the 180-day maintenance cycle for sprinklers, the 12-year scrapping period for smoke detectors, and the 6-year qualification period for operators, were uniformly retained to two decimal places. The hazard description text was uniformly truncated to 200 characters. After aggregation, the datasets were batch-flowed into subsequent verification and inference stages.

[0111] For three types of business anomalies—data deviation, verification conflict, and compliance dispute—a three-tiered resolution logic is implemented: weighted arbitration based on indicator confidence level, majority voting of multi-node verification results, and manual escalation review of high-risk documents. Each anomaly record is bound to a full-dimensional traceability field including work order ID, operation node, original data, modification trajectory, and the person handling the issue, and persistently written to an immutable audit database to retain the complete business chain. The business data governance module has a built-in hierarchical anomaly handling unit that distinguishes between the three types of business anomalies—data deviation, verification conflict, and compliance dispute—and provides three independent resolution logics. All anomaly handling processes generate complete traceability records that are written to an anti-tampering distributed audit database. The audit database is write-protected at its underlying level, and there are no interfaces for data deletion or overwriting operations.

[0112] The first type of anomaly is data deviation, which activates the indicator confidence weighted arbitration logic to assign different confidence weights to multiple sets of collected data of ledger parameters and detection values, and perform weighted calculation to output the standard valid value. For example, two sets of deviated values of 0.3MPa and 0.38MPa appear in the pressure collection of the spray pipeline, the confidence weight of equipment sensor collection is 0.7, and the weight of manual entry on the mobile terminal is 0.3. The standard value of 0.354MPa obtained through weighted arbitration is taken as the final detection data.

[0113] The second type of anomaly is verification conflict, which activates the multi-node verification result majority voting logic. When discrepancies arise in the verification results of the inspector, the reviewer and the background administrator, the conclusion with the highest proportion is taken as the valid judgment. For example, for the hot work document of the distribution room, the inspection judgment is qualified, the review judgment is unqualified, and the background review is unqualified. The negative results of the two permits are in the majority, so it is determined that the document has a verification conflict, and the rectification process is carried out on the basis of unqualified.

[0114] The third type of anomaly is compliance dispute at high-risk points, which activates the manual escalation review logic and automatically pushes it to the three-level approval account for disposal. For example, the three-level hidden danger document of the hazardous chemical warehouse scores 89 points, which is lower than the high-risk threshold of 92, resulting in a compliance dispute, and the system automatically escalates to the regional maintenance supervisor for manual review.

[0115] When any type of anomaly generates a record, the system simultaneously binds five traceability fields: the unique work order number, the current operation node identifier, all original collected data, the complete track of all previous field modifications, and the account of the disposal operator. The entire record is persistently written into the tamper-proof audit database, and the entire business link of anomaly generation and disposal can be fully restored by entering the work order number during subsequent verification.

[0116] The intelligent reasoning layer is completely deployed at the top of the six-layer architecture. The overall hardware and program architecture is a three-stage series structure consisting of a vector retrieval module, an independent business sandbox, and a scheduling controller. The three modules transmit business data in one direction in a fixed top-down order, and there is no reverse direct connection read-write channel. As the upstream data output unit, the vector retrieval module pushes the processed compliance provisions embedded in the vector standardized message down to the independent business sandbox; after the sandbox completes all compliance reasoning operations, it only encapsulates the final judgment conclusion into a message and returns it to the downstream scheduling controller; only standardized message interaction interfaces are enabled between the three modules, and memory sharing and underlying database direct connection channels are not opened. All computing processes inside the independent business sandbox only have read-only permissions for the knowledge base, and there are no operation interfaces for adding, modifying, or overwriting the ledgers, inspection records, and acceptance documents of the main business database, so no original records of any maintenance business in the system can be directly modified.

[0117] A fire protection compliance RAG knowledge base is built based on the vector retrieval framework, ① Text preprocessing rule: the maximum length of a single normative clause is 128 characters, and all redundant comments and blank lines are removed; ② General text vectorization formula: Output a fixed 512-dimensional floating-point embedding vector; ③ Cosine similarity matching formula: The retrieval matching threshold is 0.7. If the similarity is less than 0.7, the next higher level general fire protection code clauses will be recalled. The iteration termination condition is: the top 10 clauses are recalled in a single retrieval. After all similarity calculations are completed, the retrieval process is terminated. The reasoning calculation process is isolated by an independent container business sandbox.

[0118] The vector retrieval module uses a vector retrieval framework as its underlying operating support. The module's fixed input sources are three types of raw text materials: complete fire protection operation and maintenance regulations, various fire protection equipment maintenance technical specifications, and building site operation and maintenance standards. After the raw text enters the module, it undergoes a standardized preprocessing process, which includes two fixed steps: sentence and segmentation, and removal of invalid spaces, comments, and redundant characters. The processed, standardized text is then fed into a built-in vectorization algorithm for numerical conversion, uniformly generating a floating-point text embedding vector with a fixed dimension of 512. The vectorization algorithm is bound to fixed matching rules with the actual maintenance business logic. When each work order is submitted to the retrieval process, it simultaneously carries two types of tags as retrieval filters: the location risk level value and the fire protection equipment type. During the retrieval operation, it automatically filters out unmatched standard vectors, outputting only the compliant clause vector corresponding to the current work order scenario. For example, a power distribution room hot work order with a risk level value of 1 carries a high-voltage fire protection equipment tag. The retrieval process automatically filters out the general standard vector for civil fire hydrants, retrieving only the 512-dimensional embedding vector corresponding to the high-voltage pipeline hot work operation and maintenance clause and sending it to the sandbox for computation.

[0119] The independent business sandbox adopts a container cluster isolation deployment scheme. The sandbox cluster and the general business containers corresponding to the storage layer, business operation layer, and task distribution layer are allocated two completely independent virtual network segments. No inter-path routing policies are configured between the network segments. Only one one-way read-only interface is opened to receive the text vectors output by the vector retrieval module. There is no reverse data read / write path. The sandbox carries all compliance comparison and dispute determination inference calculation processes. Each container in the cluster is allocated a dedicated 2-core 4G basic computing power resource. The cluster only opens knowledge base data read permissions. All document write and field update interfaces are permanently blocked. Even if the inference process inside the sandbox experiences memory overflow, infinite loop, or other computational overflow anomalies, the process resource usage is limited to the isolated network segment container. It will not access or tamper with the core business data of the device ledger and acceptance work orders stored in the general cluster across network segments. Business data isolation and protection are achieved from both the network and container layers.

[0120] The system collects three monitoring metrics in real time: CPU load, concurrent requests, and knowledge base shard retrieval time. It also dynamically adjusts computing power quotas in conjunction with the scheduling controller. The sandbox abnormal circuit breaker judgment rules are as follows: if the CPU of a single inference container is continuously occupied at 90% for more than 120 seconds, or if the single shard retrieval time exceeds 2000ms, the inference process is determined to be in an infinite loop. The current sandbox Pod is automatically destroyed and a new isolated container is restarted. At the same time, the current work order is cached and inference is restarted to avoid work order loss.

[0121] The scheduling controller and the other two modules of the intelligent inference layer establish a real-time monitoring data synchronization channel to continuously collect three types of real-time hardware and business operation indicators. These indicators are: real-time CPU utilization percentage of the server, total number of concurrent requests across the entire system, and single-time vector retrieval time for a single knowledge base shard. Each indicator corresponds to a set of fixed resource dynamic adjustment rules. Once a rule is triggered, the operating parameters of the sandbox and retrieval modules are adjusted immediately. The first adjustment rule is as follows: when the real-time CPU load value exceeds 80%, the controller issues a computing power expansion command, and the CPU and memory quotas allocated to the inference container are simultaneously increased by 30%. The second adjustment rule is as follows: when the total number of concurrent requests in the current system exceeds a preset baseline of 120, the controller lowers the real-time processing concurrency threshold of the inference module to 80, and excess requests are queued in an ordered buffer queue. The third adjustment rule is as follows: when the time for a single knowledge base shard to execute a vector retrieval exceeds 1200 milliseconds, the controller automatically adds two sets of parallel retrieval shards to synchronously share the vector matching operation.

[0122] For example, during weekday daytime, when maintenance documents for a commercial complex are entered in batches, the system simultaneously generates 135 concurrent requests awaiting inference. The server's real-time CPU usage is 86%, and the time taken for a single vector retrieval in any knowledge base shard reaches 1400 milliseconds. All three indicators trigger the corresponding adjustment rules. The scheduling controller simultaneously issues three adjustment instructions: the first increases the computing power of the sandbox inference container by 30%; the second lowers the inference concurrency processing threshold from 120 to 80, with the remaining 55 requests entering the time-series buffer queue; the third adds two sets of parallel retrieval shards to simultaneously perform text vector matching. After shard parallel processing, the average time taken for a single retrieval decreases to 620 milliseconds, significantly shortening the overall time for work order compliance inference. In high-concurrency scenarios, the inference process does not experience lag or timeout issues.

[0123] The layered data processing and isolated inference architecture balances the throughput of routine work order batch processing with the compliant closed-loop handling of abnormal work orders. A sandbox isolation mechanism prevents unauthorized inference tasks from contaminating the main business, and dynamic resource scheduling can smooth out peak periods and handle concurrent pressure during maintenance operations. The front-end layered data processing unit is deployed within the business operation layer's visual workflow engine, with all computing resources prioritized by default. The unit's core processing tasks include unified cleaning of multi-source maintenance documents, automatic splitting of cross-position collaborative sub-tasks, and aggregation of multi-dimensional job fields. The overall design goal is to increase the system's parallel throughput capacity for large batches of documents, with a single batch processing capacity of 1000 inspection and maintenance documents per unit. The post-isolated inference unit corresponds to the intelligent inference layer vector retrieval module and the business sandbox combination structure. It independently occupies the computing power of the isolated cluster and is only responsible for two types of calculation tasks: fire protection compliance clause vector matching and intelligent judgment of work order compliance disputes. The core design goal is to isolate the risk of resource crowding out of basic business caused by high-load inference operations. The two types of units are connected and work together to complete the complete closed-loop link of work orders from original entry to compliance judgment. Each document needs to complete hierarchical data aggregation first before being sent to the isolated inference unit for calculation.

[0124] The sandbox isolation mechanism consists of two layers of protection logic: network segment isolation and container computing resource isolation. These two layers of rules take effect simultaneously, comprehensively preventing abnormal inference processes from interfering with core business processes such as inspection, work order distribution, and ledger synchronization. At the network isolation level, the isolated sandbox cluster is allocated an independent virtual network segment, with no interconnection routes with the general business container network segment, preventing the inference process from initiating network requests to access the general cluster. At the computing resource isolation level, sandbox containers are allocated a dedicated computing quota pool, completely separated from the general container computing pool used for processing ledgers, personnel qualifications, and work order distribution. High-consumption compliance vector retrieval and multi-dimensional dispute inference tasks only consume the sandbox's independent quota and do not preempt the general container's CPU and memory resources. For example, a single sandbox container has a basic computing power of 2 cores and 4GB, while the general work order container defaults to 1 core and 2GB. When the sandbox inference process's CPU usage reaches a maximum of 95%, the general container's CPU usage remains stably below 30%, ensuring that automatic work order distribution and personnel qualification verification processes do not experience delays or stalls.

[0125] The scheduling controller incorporates dynamic resource peak-shaving and valley-filling scheduling logic. Based on real-time monitoring of the number of concurrent work orders and the total number of inference requests, it automatically adjusts the isolation sandbox computing power quota and the number of parallel shards in the knowledge base, implementing two sets of resource allocation rules for peak and off-peak periods. Off-peak periods are defined as 300 consecutive seconds without any high-risk hot work or stress testing work orders awaiting inference, triggering resource reduction rules. This simultaneously reduces the computing power of the inference container and decreases the number of parallel retrieval shards. The released computing power and memory resources are automatically allocated to basic tasks such as storage layer ledger synchronization, permission layer qualification verification, and task distribution layer personnel matching. Peak maintenance periods are defined as more than 120 new inference work orders added within a 60-second polling cycle, triggering resource expansion rules. This simultaneously increases the sandbox computing power by 30% and adds parallel retrieval shards to handle the large volume of synchronous inference requests, preventing resource exhaustion in the inference module from causing work order dispatch chain blockage.

[0126] During the off-peak period from midnight to 2 a.m., the system has no hot work or high-risk inference documents for pressure detection. The scheduling controller identifies that the inference concurrency is 0 for 420 consecutive seconds and executes the downsizing rule, reducing the computing power of the original 4 groups of inference containers to the basic 1 core 2G specification. The parallel sharding of the knowledge base is reduced from 6 groups to 2 groups. All the freed computing power resources are scheduled to start the full synchronization task of the ledger at 2 a.m. every day. This ensures that the synchronization of massive equipment data such as the 180-day maintenance cycle of sprinkler heads and the 12-year scrapping age of smoke detectors is completed stably within a 45-minute window. The synchronization process does not occupy inference resources. During the peak maintenance period of the shopping mall from 9:00 to 18:00, mobile devices uploaded inspection and hot work rectification documents in batches. A single polling test generated 135 concurrent inference requests, exceeding the baseline threshold of 120. The controller simultaneously performed two expansion operations: the computing power of each container in the sandbox was increased by 30%, and the parallel sharding of the knowledge base was expanded from 2 groups to 4 groups. Multiple work orders from the shopping mall's power distribution room and hazardous chemical warehouse could simultaneously complete 512-dimensional compliance clause vector matching calculations. The inference time for a single document was reduced from 1400 milliseconds to less than 600 milliseconds. There were no queuing, blocking, or process interruption issues in the parallel processing of large batches of documents.

[0127] Three typical park types—office buildings, manufacturing plants, and hospitals—were selected, and a control group (traditional fixed-area manual dispatch system) and an experimental group (the six-layer digital management solution of this invention) were set up. Quantitative indicators were collected for 30 consecutive days: the average work order processing time was 142 minutes in the control group and 48 minutes in the experimental group, representing a 66.2% improvement in processing efficiency. The high-risk hazard omission rate was 21.7% in the control group and 3.9% in the experimental group, significantly reducing compliance risks. The average daily work order load balance for maintenance personnel was 12 fewer work orders than in the control group and 3 fewer work orders than in the experimental group, indicating a balanced workload. The system's peak concurrent capacity was 420 work orders / day in the control group and 1350 work orders / day in the experimental group, with no lag during peak periods. The average server computing power utilization was 0.82 cores in the cloud for the control group and 0.29 cores in the edge sandbox for the experimental group, resulting in a 64.6% saving in computing resources.

[0128] This invention's layered architecture, AHP intelligent dispatching, and isolated RAG inference mechanism are adaptable to various building parks. It boasts quantifiable and significant advantages in multiple dimensions, including processing efficiency, compliance identification, concurrency handling, and hardware computing power. The technical effects are verifiable through field testing, not theoretical deduction. In one implementation, such as Figure 2 As shown, this application also provides a digital management device for the entire fire protection maintenance process, including: The 201 maintenance and repair full-domain data access module is used to collect multi-source basic data such as fire equipment ledgers, maintenance points, and personnel qualification files, covering the entire chain of business documents for inspection, maintenance, rectification, and acceptance, aligning fire compliance provisions with on-site operation and maintenance standards, and completing the unified storage of multi-source business raw data; The layered architecture specification defines module 202, which is used to divide the functional boundaries of each subsystem in accordance with the principles of single responsibility, full-link closed loop, and scalable design, configure the compliance verification thresholds for general and high-risk maintenance, configure the scenario switching rules driven by business events, and build a six-layer digital overall architecture for fire protection maintenance, including storage, permissions, scheduling, tasks, business, and inference. The Business Resource and Access Control Module 203 is used to perform integrated scheduling of data schema verification, business dependency parsing, process template reuse, and idle resource unloading. It constructs a two-dimensional permission matrix of personnel accounts and equipment locations, divides the operation granularity into three levels of viewing, editing, and approval, and uses container sandboxes to isolate high-risk maintenance processes and implements full-link operation audit and traceability. The maintenance work order intelligent routing and distribution module 204 is used to build a multi-dimensional scoring routing model based on task matching accuracy, personnel load, hazard level, and work order urgency. It distinguishes work order types based on comprehensive scoring thresholds and executes two types of distribution logic: automatic allocation by the system and Top-K bidding for personnel to claim the work order. It also permanently fixes the core priority parameters of work order scheduling. The Business Data Governance and Intelligent Reasoning Scheduling Module 205 is used to break down cross-position collaborative sub-tasks based on business complexity, aggregate multi-dimensional maintenance operation fields, and configure hierarchical resolution and full-link traceability mechanisms for data deviation, verification conflict, and compliance disputes. It builds an intelligent reasoning foundation based on the fire protection compliance RAG knowledge base and an independent business sandbox, and dynamically and adaptively adjusts the system's computing power quota, concurrency limit, and knowledge base retrieval parallel parameters in real time.

[0129] The computer-readable storage medium provided in the above embodiments of this application and the digital management method for the entire fire protection maintenance process provided in the embodiments of this application are based on the same inventive concept and have the same beneficial effects as the methods adopted, run or implemented by the application stored therein.

[0130] The various embodiments in this application are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments for evaluating the digital management method, electronic device, electronic device, and readable storage medium for the entire fire protection maintenance process are basically similar to the embodiments of the aforementioned digital management method for the entire fire protection maintenance process, and are therefore described simply. Relevant parts can be referred to in the descriptions of the embodiments of the aforementioned digital management method for the entire fire protection maintenance process.

Claims

1. A digital management method for the entire fire protection maintenance process, characterized in that, include: Obtain fire equipment ledgers, maintenance locations, and personnel qualification data, covering the entire business chain of inspection, maintenance, rectification, and acceptance, and aligning fire safety compliance regulations with on-site operation and maintenance standards; Based on the principles of single responsibility, full-link closed loop, and scalability, the system functional boundaries are defined, maintenance compliance dual verification thresholds are set, standardized business scenario switching rules are established, and a six-layer digital system architecture for fire protection maintenance is built. Complete the integrated scheduling of data verification, business parsing, template reuse, and resource unloading; build a two-dimensional permission matrix for personnel and equipment; divide the operation granularity into three levels; and implement a high-risk business isolation and full-process audit and traceability mechanism. By combining task accuracy, personnel load, potential risks and urgency to build a routing strategy, and relying on a comprehensive scoring threshold, a dual distribution logic of automatic allocation and Top-K bidding claim is realized, and core business priority data is solidified. Collaborative sub-tasks are broken down according to business complexity, and multi-dimensional operational data is aggregated. Intelligent resolution and traceability mechanisms are configured for data deviations, verification conflicts, and compliance disputes. An intelligent reasoning system is built based on a compliance knowledge base and a business sandbox to achieve adaptive scheduling of system computing power, concurrency, and retrieval parameters.

2. The method as described in claim 1, characterized in that, Based on the principles of single responsibility, closed-loop end-to-end, and scalability, the system's functional boundaries are defined, dual verification thresholds for maintenance compliance are set, standardized business scenario switching rules are established, and a six-layer digital fire protection maintenance system architecture is built, including: Based on the three major architectural design principles of single responsibility, full-link closed loop, and scalability, the business is divided into micro-modules. The functional boundaries of each subsystem are clearly defined according to data, permissions, scheduling, tasks, business, and inference domains. Cross-module coupling is isolated through interface contracts. Configure two sets of judgment standards: a general maintenance compliance threshold and a high-risk operation special verification threshold. The two thresholds are linked to verify the compliance of business documents. The entire process of inspection, maintenance, hazard rectification and final acceptance is streamlined, and standardized scenario switching is driven by business event triggers, with a corresponding scenario parameter snapshot reuse mechanism. The system is divided into six layers: storage layer, permission layer, resource scheduling layer, task distribution layer, business operation layer, and intelligent inference layer. The system sequentially completes data schema verification, permission matrix loading, task scheduling engine deployment, business process template configuration, and intelligent inference base access, thus implementing the complete digital fire protection maintenance system architecture in stages.

3. The method as described in claim 1, characterized in that, The system integrates data verification, business parsing, template reuse, and resource unloading scheduling; establishes a two-dimensional personnel-equipment permission matrix; defines three levels of operational granularity; and implements high-risk business isolation and a full-process audit and traceability mechanism, including: An integrated scheduling pipeline is built on a distributed microservice scheduling middleware. The built-in structured data schema verification rule engine parses the field specifications of maintenance ledgers and inspection records. The upstream and downstream dependencies of the business are parsed through a directed acyclic graph (DAG). Redis is used to cache standardized business templates to achieve reuse and acceleration. Idle Pods are dynamically unloaded based on container resource monitoring indicators, and memory and computing resources are released on a regular basis. Construct a two-dimensional permission matrix of personnel account ID and fire equipment location code, configure the RBAC permission control model, divide the operation granularity into three levels of read-only viewing, form editing, and process approval, and connect to the gateway permission interceptor to parse the request identity and perform matching and verification with the device permission in real time. High-risk maintenance processes involving hot work and pressure testing are isolated using independent container sandboxes. Cross-service data access whitelists are configured to block unauthorized data reading and writing. Full logs of operator, terminal IP, operation time, modified fields, business document number, and device number are collected synchronously, written to a distributed time-series database, and tamper-proof encrypted storage of logs is enabled. Three types of control parameters are set: permission matching timeout threshold, mandatory manual review switch for high-risk operations, and off-site backup cycle of audit logs. These parameters work in conjunction with the scheduling engine, permission gateway, sandbox container, and log storage component to achieve automated verification of the entire chain of resource scheduling, permission classification, risk isolation, and operation traceability.

4. The method as described in claim 1, characterized in that, A routing strategy is constructed by combining task accuracy, personnel load, potential risks, and urgency. Based on a comprehensive scoring threshold, it achieves automatic allocation and Top-K bidding claiming dual distribution logic, and solidifies core business priority data, including: A multi-factor weighted task routing scoring model was built by combining four dimensions: task matching accuracy, on-duty personnel load, on-site hazard level, and work order urgency. The analytic hierarchy process (AHP) was used to assign fixed weights to each dimension. After normalizing the original index values, the weighted sum was used to obtain the comprehensive work order score. The system allows for the configuration of a comprehensive scoring threshold to divide work orders into two categories. Regular work orders with scores below the threshold are automatically assigned based on personnel qualification tags, geographical distance to the work site, and current pending workload to find the best personnel for the work order allocation. The scheduling engine then issues work orders in batches. High-priority work orders with scores above the threshold use a Top-K bidding mechanism to select K personnel with the corresponding special operation qualifications and push them to the bidding window. The system also allows for setting bidding time limits and daily order limits for each person. The core business priority data, such as personnel skill classification tags, equipment hazard risk classification, work order time limit weight, and scoring weight of each dimension, are persistently stored in the distributed configuration center to solidify the basic routing parameter pool and support the backend to visually and dynamically adjust the weight iteration distribution strategy. Based on the timed polling interface, real-time indicators such as personnel load, hazard handling progress, and remaining time of work orders are retrieved. The comprehensive score of work orders is periodically recalculated to drive the scheduling gateway to switch between two types of distribution processes: automatic allocation and bidding claiming. The work order scoring record, personnel matching record, and bidding interaction log are fully retained.

5. The method as described in claim 4, characterized in that, Break down collaborative sub-tasks based on business complexity, aggregate multi-dimensional operational data, and configure intelligent resolution and traceability mechanisms for data deviations, verification conflicts, and compliance disputes; Based on a compliance knowledge base and business sandbox, an intelligent reasoning system is built to achieve adaptive scheduling of system computing power, concurrency, and retrieval parameters, including: Regular maintenance work orders rely on a visual workflow engine to analyze business complexity thresholds, automatically break down cross-position collaborative sub-tasks, and complete the structured aggregation of multi-dimensional operation data through a unified data middleware layer that standardizes cleaning equipment ledgers, personnel qualifications, and inspection and rectification multi-source fields, adapting to the scenario of batch processing of large batches of standardized maintenance documents; For three types of business anomalies—data deviation, verification conflict, and compliance dispute—a three-level resolution logic is implemented: weighted arbitration based on indicator confidence level, majority voting of multi-node verification results, and manual escalation review of high-risk documents. Each anomaly record is bound to a full-dimensional traceability field including work order ID, operation node, original data, modification trajectory, and the person in charge, and is persistently written to an immutable audit database to retain the complete business chain. A fire safety compliance RAG knowledge base is built based on a vector retrieval framework. An independent container business sandbox is used to isolate the inference computing process and avoid abnormal inference tasks from interfering with core business. Three types of monitoring indicators are collected in real time: service CPU load, number of concurrent requests, and knowledge base shard retrieval time. The scheduling controller is linked to dynamically adjust the computing power quota, concurrent rate limit threshold, and retrieval shard parallelism parameters to achieve intelligent inference layer resource adaptive scheduling. The layered data processing and isolated inference architecture balances the throughput of batch processing of regular work orders with the compliant closed-loop handling of abnormal work orders. The sandbox isolation mechanism avoids illegal inference tasks from polluting the main business, and dynamic resource scheduling can smooth out peak and valley periods and smoothly cope with the concurrent pressure of maintenance business during peak periods.

6. A digital management device for the entire fire protection maintenance process, characterized in that, The system is configured to execute the digital management method for the entire fire protection maintenance process as described in any one of claims 1 to 5 by executing executable instructions.

7. An electronic device, characterized in that, include: First processor; and memory for storing executable instructions of the first processor; The first processor is configured to execute the digital management method for the entire fire protection maintenance process as described in any one of claims 1 to 5 by executing the executable instructions.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the second processor, it implements the digital management method for the entire fire protection maintenance process as described in any one of claims 1 to 5.

Images