Multi-terminal management and control system and method based on blockchain pre-depositing

Abstract

The application discloses a multi-terminal management and control system and method based on a blockchain pre-storage record, a storage medium and electronic equipment, and belongs to the technical field of distributed management and control and blockchain storage record. The system comprises a processing unit and a blockchain storage unit coupled in bidirectional communication, and the two constitute an inseparable mandatory management and control architecture; the processing unit completes full-link verification through a hierarchical permission verification link in cascade connection, chains storage record of instructions and process data that pass the verification, obtains a unique binding hash value and a storage record result, and issues an instruction only when the storage record passes and the hash value matches through the mandatory management and control logic that cannot be bypassed, otherwise, the instruction is intercepted in an all-inclusive manner, and finally, a secondary chain storage record closed loop is completed by receiving an execution result. The application realizes a full-link trusted closed loop of multi-terminal management and control, and can be widely applied to multi-terminal cluster management and control scenes such as industrial manufacturing and multi-site health services.

Description

Technical Field

[0001] This invention relates to the field of distributed control and blockchain evidence storage technology, specifically to a multi-terminal control system, method, storage medium, and electronic device based on blockchain pre-existing evidence storage, corresponding to the national key development category of "New Generation Information Technology Industry - Internet of Things - Internet of Things Platform Services" in the "Strategic Emerging Industries Classification (2024)". This invention is only used for the linkage control of industrial intelligent equipment, general IoT intelligent equipment, and non-medical health service intelligent equipment, and does not involve any disease diagnosis or treatment methods, nor should it be applied to scenarios related to disease diagnosis, treatment, or prevention in humans or animals. The implementing entity of this solution is a non-medical institution, and all supporting terminal equipment are non-diagnostic, non-invasive daily monitoring and control equipment, providing routine services only to healthy individuals, and does not involve diagnostic and treatment activities as stipulated in the "Regulations on the Administration of Medical Institutions," fully complying with national laws and regulations and patent examination rules. Background Technology

[0002] Existing distributed multi-terminal management and control systems, especially those applied to multi-site distributed services, industrial production lines, and other multi-terminal cluster management and control scenarios, generally suffer from the following problems:

[0003] First, the architecture is highly coupled, with business application logic and cloud-based underlying management logic deeply bound together. The high degree of coupling between the two leads to blurred boundaries of responsibilities, resulting in a severe lack of horizontal scalability. Changes to business processes require modifications to the core cloud code, leading to long iteration cycles and failing to meet the core needs of rapid business iteration.

[0004] Second, the lack of a flexible, configurable hierarchical access control mechanism means that instructions are sent directly from the cloud to devices without end-to-end hierarchical verification, leading to a high rate of unauthorized operations. Furthermore, the absence of a built-in compliance verification and interception mechanism means that access nodes cannot be flexibly adjusted according to regulatory requirements, posing serious security risks. It also fails to adapt to the hierarchical access control needs of multiple entities and cross-industry sectors, making it impossible to guarantee data security and access boundaries when multiple authorized entities are connected. Existing technologies typically employ a single access node or parallel access node architecture. Single nodes are easily compromised, while parallel nodes can bypass controls through skip-level approvals, failing to fundamentally eliminate unauthorized operations.

[0005] Third, blockchain-based evidence storage is merely an add-on module for post-event auditing, not embedded in the core process of instruction execution. It cannot achieve mandatory control of "evidence storage before execution," and its evidence storage architecture has poor adaptability, supporting only a single chain architecture. It cannot accommodate scenarios of multi-entity collaboration and single-entity control, resulting in a high risk of instruction tampering and a low compliance audit pass rate. Furthermore, it cannot achieve full-process chain-based evidence storage of service recipient identity, health data, and transaction data, leading to insufficient data traceability. Existing technologies only store evidence of the final instruction, failing to cover data from the authorization verification process and execution process, thus creating vulnerabilities for post-event approval, tampering with approval records, and falsifying execution results.

[0006] Fourth, all data processing is concentrated in the cloud, resulting in high computing pressure, high network latency, and high response delays for real-time control commands; offline management is disconnected from cloud management, and there is no compliance and integrity verification mechanism after network recovery, leading to a high deviation rate between offline business data and cloud data, and data consistency cannot be guaranteed.

[0007] Fifth, control rules can be easily bypassed. Existing system control rules are usually stored in cloud databases, and control can be bypassed by modifying database configurations or system parameters, which cannot meet the compliance requirements of strongly regulated scenarios.

[0008] Sixth, it cannot achieve seamless integration of multiple heterogeneous systems, resulting in severe data silos. It cannot achieve standardized data interaction with third-party business management systems, and online and offline data are fragmented. Data from all channels cannot achieve real-time synchronization and unified mapping across the entire domain, thus failing to support the integrated operation needs of multiple business formats and all channels.

[0009] Seventh, there is a lack of a universal end-to-end health status data processing architecture, which makes it impossible to achieve standardized processing of multi-terminal data collection, benchmarking analysis, and trend visualization, and thus cannot provide data support for the entire business process.

[0010] None of the aforementioned existing technologies address the root causes of the problems in the system architecture. They merely patch the issues by adding permission or evidence storage modules in the cloud, further exacerbating the cloud computing pressure and architectural chaos. Moreover, they cannot simultaneously solve the five core problems of "pre-verification of permissions, prevention of command tampering, non-bypassable control rules, closed-loop control between offline and online, and fusion of data from all channels." There are irreconcilable technical contradictions between permission control and low latency, evidence storage compliance and execution efficiency, and offline control and compliance consistency. Summary of the Invention

[0011] Technical problems to be solved

[0012] To address the aforementioned shortcomings of existing technologies, this invention provides a multi-terminal management and control system, method, storage medium, and electronic device based on blockchain-based pre-existing evidence storage. This solves the technical pain points of existing distributed management and control systems, such as high coupling, insufficient compliance, delayed evidence storage, disconnect between offline and external management, easy bypassing of management rules, severe data silos, insufficient omnichannel data fusion capabilities, and poor adaptability to multiple entities. Simultaneously, it resolves the irreconcilable technical contradictions in existing technologies regarding access control versus cloud load, evidence storage compliance versus execution efficiency, and offline management versus compliance consistency.

[0013] Technical solution:

[0014] All technical solutions of this invention are based on the same core inventive concept, namely, through a full-link closed-loop architecture of "tiered permission pre-verification - blockchain pre-existing evidence storage - unavoidable mandatory control - closed-loop execution of execution unit - full-process secondary evidence storage", to achieve secure, efficient and reliable control of multiple terminal devices. All independent claims are based on this core inventive concept and comply with the patent law's requirements on unity of invention.

[0015] In the first aspect, the present invention provides a multi-terminal management and control system based on blockchain pre-existing evidence storage, including a processing unit with bidirectional communication coupling and a blockchain evidence storage unit. The two constitute an inseparable mandatory management and control architecture for the entire management and control process. Complete management and control cannot be achieved if any unit is missing.

[0016] After receiving a control instruction request, the processing unit must complete the full-link verification through a hierarchical permission verification link formed by at least two logically independent permission verification nodes. If any node fails verification, the instruction will be directly intercepted. Only control instructions that have completed the full-link verification can be synchronized to the blockchain evidence storage unit.

[0017] The blockchain evidence storage unit performs tamper-proof on-chain evidence storage of the received control instructions and end-to-end verification process data, generates a uniquely bound hash value, and feeds back the evidence storage verification result to the processing unit in real time. The processing unit has built-in unbypassable mandatory control execution logic, and can only issue instructions to the terminal for execution when the evidence storage verification is passed and the hash value matches. Instructions that fail the verification are all intercepted.

[0018] After receiving the execution result from the terminal, the processing unit must synchronize the execution result and all process data to the blockchain evidence storage unit to complete the secondary on-chain evidence storage, forming a unique evidence storage closed loop for the entire control process.

[0019] Furthermore, the mandatory control execution logic built into the processing unit is a fixed logic. This fixed logic cannot be changed or bypassed through unauthorized configuration modifications, background operations, program interface calls, or unauthorized firmware upgrades. It can only complete the compliance logic iteration through a preset smart contract upgrade process with multi-node joint authorization.

[0020] Furthermore, the mandatory control execution logic is solidified and deployed through a blockchain smart contract. Once deployed, the core execution logic of the smart contract cannot be modified. The deployment and upgrade of the smart contract require verification through pre-set multi-node joint authorization, and a single node cannot complete the contract modification.

[0021] Furthermore, the processing unit includes logically decoupled application layer subunits, cloud layer subunits, and execution subunits. The application layer subunits, cloud layer subunits, and execution subunits are sequentially connected bidirectionally to form a closed-loop architecture for the entire control chain. The application layer subunit has a built-in permission verification node for initiating control commands and performing hierarchical permission verification. The cloud layer subunit has a built-in forced control execution logic for verifying and scheduling control commands. The execution subunit receives and executes control commands and sends the execution results back to the processing unit.

[0022] Furthermore, the execution subunit includes a side-layer control subunit and an end-layer terminal subunit with bidirectional communication connection. The side-layer control subunit and the cloud subunit are bidirectionally connected and used to complete cloud instruction forwarding and edge-side preprocessing. The end-layer terminal subunit is the final execution carrier of the control instructions.

[0023] Furthermore, the permission verification node includes a first permission node, a second permission node, a third permission node, and a fourth permission node; each permission verification node can be logically merged into one or more verification nodes, or split into multiple step-by-step verification nodes, according to the regulatory level requirements of the control scenario.

[0024] Furthermore, the last-level node of the permission verification node has a built-in customizable compliance rule library. The compliance rule library is used to verify the rule compliance of control instructions and to trigger interception operations and warning prompts for control instructions that do not comply with preset rules. The compliance rule library is globally configured and synchronized to all last-level permission nodes.

[0025] Furthermore, the blockchain evidence storage unit is built on a consortium blockchain or private blockchain network, and performs calculations on all elements of the control command using the national cryptographic SM3 algorithm or SHA-256 algorithm to generate a hash value uniquely bound to the control command; the evidence storage verification result includes evidence storage integrity conclusion, command consistency conclusion, consensus validity conclusion, block identifier, and on-chain timestamp information.

[0026] Furthermore, the processing unit has built-in repeated trigger interception logic. For the same control instruction, the same service object, and the same type of rights, after completing the rights calculation and status solidification, it automatically identifies and intercepts all subsequent requests of the same type.

[0027] Furthermore, the edge-layer control subunit incorporates a local control module and a network status monitoring module. The local control module incorporates offline permission verification rules and an instruction cache library that are synchronized globally, used to complete independent local control of control instructions and data caching when the network is interrupted. The network status monitoring module is used to monitor network connectivity in real time, triggering the switching of network outage control mode and the resumption of interrupted transmission and data synchronization operations after network recovery. When synchronizing data after network recovery, the integrity of the cached offline execution data needs to be verified through the blockchain notarization unit. Only after the verification is passed can the full-link data synchronization be completed.

[0028] Furthermore, the cloud subunit also incorporates at least one of the following: a global rule configuration module, an intelligent scheduling module, a distributed storage module, a load balancing module, a cross-system interface adaptation module, an omnichannel data synchronization module, and a multi-subject adaptation unit.

[0029] Furthermore, the cross-system interface adaptation module incorporates a multi-protocol adaptation unit, a national cryptographic encryption transmission unit, and a data consistency verification unit, which are used to achieve standardized encrypted data interaction and consistency verification with third-party heterogeneous business systems; the omnichannel data synchronization module is used to achieve real-time synchronization and unique identifier mapping of omnichannel data between offline business nodes and online service ports.

[0030] Furthermore, the multi-subject adaptation unit is used to implement hierarchical permission configuration and access control for different authorized subjects, and supports setting independent role permissions, data access scope, and operation boundaries for different subjects.

[0031] Furthermore, the processing unit also has a built-in health data processing module, which is used to complete the standardized processing of health status data across the entire chain and the full-process access control; the health data processing module includes a data acquisition unit, a structured processing unit, an analysis unit, a visualization generation unit, and a time-series data storage unit; the blockchain notarization unit is also used to perform chain-based notarization of the unique identity of the service object, the time-series health status data, and the transaction event data across all channels.

[0032] Furthermore, the terminal sub-unit includes various business terminals, service terminals, and management terminals. Each terminal corresponds to a unique device identifier and permission scope, and each terminal is bound to the execution scenario of the control command.

[0033] Secondly, this invention provides a multi-terminal management method based on blockchain pre-existing evidence storage, applied to any of the systems described above, comprising the following steps: S1 receives a control command and initiates a request. It performs full-link hierarchical permission verification on the control command through a hierarchical permission verification link formed by at least two logically independent permission verification nodes and executed in a preset order. It must pass through all the preceding verification nodes in a preset order. If the verification of the previous node fails, it cannot enter the next verification node. If the verification of any permission node fails, the command is directly intercepted. S2 will complete the control instructions for full-link hierarchical permission verification, and send them along with the full-link permission verification process data to the blockchain evidence storage unit to complete on-chain evidence storage, and obtain the hash value and evidence storage verification result that are uniquely bound to all elements of the control instructions and the full-link verification process data. S3 executes control based on its built-in mandatory control logic: the chain storage must be completed and the storage verification result must be obtained before the instruction scheduling stage can begin. The control instruction will only be scheduled and sent to the corresponding terminal for execution when the storage verification result corresponding to the control instruction is received and the storage verification result matches the data of the control instruction's full elements and the entire chain verification process through a unique hash value binding. Instructions that fail the storage verification or whose hash values ​​do not match will be intercepted and rejected from scheduling. S4 receives the instruction execution results from the terminal, sends the execution result data and the entire instruction execution process data to the blockchain evidence storage unit to complete the secondary on-chain evidence storage, forming a closed loop for the entire process of control and evidence storage.

[0034] Furthermore, in step S1, each permission verification node can be logically merged into one or more verification nodes, or split into multiple step-by-step verification nodes, according to the regulatory level requirements of the control scenario.

[0035] Furthermore, step S3 also includes: if the edge layer control subunit detects a network interruption with the cloud layer subunit through the network status monitoring module, it immediately triggers the offline control mode, completes the local permission verification, local execution and data caching of the control command through the local control module, and after the network is restored, transmits the cached offline execution data to the blockchain evidence storage unit for integrity verification, and completes the full-link data synchronization after the verification is passed.

[0036] Thirdly, the present invention provides a non-transitory tangible computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it implements all the steps of the aforementioned multi-terminal control method. The computer-readable storage medium includes tangible media capable of storing computer program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, and optical disks, but does not include transient propagation signals.

[0037] Fourthly, the present invention provides an electronic device, including a processor and a memory, wherein the memory stores a computer program that can run on the processor, and when the processor executes the computer program, it implements all the steps of the above-described multi-terminal management and control method, and / or runs the multi-terminal management and control system described in any of the above-described embodiments. The electronic device includes devices with data processing and program execution capabilities, such as industrial control computers, cloud servers, edge gateways, and smart terminals.

[0038] Beneficial effects

[0039] Compared with the prior art, the present invention has the following objective technical effects, and corresponds one-to-one with the defects of the prior art:

[0040] 1. Achieve complete decoupling of the architecture, significantly improving system scalability. Through a three-level logical decoupling architecture of processing unit layer, cloud layer, and execution layer, the business application logic is completely separated from the underlying management logic. The system supports simultaneous management of large-scale nodes and devices, greatly improving horizontal scalability. Business process changes can be quickly configured without modifying the core cloud code. Compared with existing technologies, business iteration efficiency is improved by more than 300% (the benchmark is a traditional architecture with deep coupling between business logic and cloud management).

[0041] 2. Achieve end-to-end security control and completely eliminate the risk of unauthorized operations. Through a hierarchical permission verification mechanism that executes sequentially according to a preset order, coupled with a globally synchronized compliance rule library built into the last-level permission node, pre-interception and compliance confirmation are achieved at the instruction initiation stage. If the verification of the previous node fails, the next stage cannot proceed, thus eliminating skipped-level approval and unauthorized operations at the source. Through the mandatory control logic of "first storage, then execution," blockchain storage is embedded into the core process of instruction execution. Combined with a closed loop of secondary storage throughout the entire process, the entire control process is traceable, and the compliance audit pass rate is increased to over 99%. Through multi-entity adaptation units, hierarchical permission control for different authorized entities is achieved, and data security and permission boundaries are fully guaranteed, adapting to the alliance operation needs of multiple business formats and multiple entities.

[0042] 3. Achieve flexible adaptation of the evidence storage architecture, significantly reducing cross-scenario adaptation costs. Adopting a permissioned blockchain architecture, it can be flexibly configured as a consortium blockchain or a private blockchain according to scenario requirements. This satisfies the consensus control needs of consortium blockchains in scenarios with strong multi-entity regulation, and also adapts to the lightweight control needs of private blockchains in scenarios with multiple single-entity, multi-terminal applications, reducing cross-scenario adaptation costs by 80%. By storing all elements and the entire verification process of control instructions on the blockchain, vulnerabilities such as instruction tampering and approval record supplementation are completely blocked. This is highly differentiated from existing technologies that only store the final instruction, significantly enhancing the level of innovation.

[0043] 4. Achieve fully closed-loop consistency management both online and offline. Through the local management module and network status monitoring module of the edge-layer management subunit, independent local management is achieved in the event of a network outage. After the network is restored, the integrity verification of offline data is completed through the blockchain notarization unit. The offline data synchronization consistency reaches over 99.99%, completely solving the problems of disconnect between online and offline management and data inconsistency, and ensuring the compliance of offline management operations.

[0044] 5. Ensuring the unbypassability of control rules. The mandatory control execution logic is defined and solidified through the first-level dependent claims, supporting multiple solidified deployment methods. Compliance updates can only be performed through a complete firmware version upgrade; it cannot be bypassed by modifying database configurations, system parameters, background operations, or decompilation. This ensures the authority of the control rules at the architectural level, meeting the compliance requirements of heavily regulated scenarios. Simultaneously, the exclusive right does not impose this restrictive limitation, maximizing the scope of protection and balancing the protection needs of both general and heavily regulated scenarios.

[0045] 6. Achieve omnichannel data integration and seamless cross-system integration. Through the cross-system interface adaptation module, standardized encrypted data interaction with third-party heterogeneous business systems is achieved, breaking down data silos; through the omnichannel data synchronization module, real-time synchronization and unique identifier mapping of omnichannel data across offline business nodes and online service ports are achieved, reducing data synchronization latency to less than 1 second and achieving data consistency of 99.99%, perfectly adapting to the needs of integrated omnichannel operations.

[0046] 7. Achieve standardized processing of health status data across the entire process. Through the built-in health data processing module, it achieves standardized processing of multi-terminal data collection, benchmarking analysis, and trend visualization, forming a time-series health database. This provides standardized data support for the entire business process, improving data processing efficiency by over 200%.

[0047] 8. Achieve end-to-end data immutability and traceability. By storing authorization verification process data, instruction execution process data, and control instructions together on the blockchain and generating a uniquely bound hash value, it is ensured that any data tampering at any stage will result in a hash value mismatch, thus eliminating the possibility of data tampering at the source and meeting the compliance audit requirements of highly regulated scenarios.

[0048] 9. An indivisible mandatory control architecture with bidirectional coupling and strong binding across the entire chain between the processing unit and the blockchain evidence storage unit was constructed. The entire process of control instructions, from step-by-step verification, pre-existing evidence storage, compliant execution to closed-loop evidence storage, is interconnected. The deletion of any link or the separation of any unit will directly lead to the complete break of the entire control loop, making it impossible to achieve the core mandatory control effect of "evidence storage first, execution later". This architecture completely solves the infringement avoidance risks caused by module splitting, link deletion, and process adjustment, maximizes the scope of patent protection, and at the same time lays a complete specification support for the application of the equivalent principle in subsequent infringement litigation.

[0049] The aforementioned technical effects are not the sum of the effects of each technical feature implemented individually, but rather the result of the organic synergy of five core features: hierarchical access control, blockchain pre-existing evidence storage, unavoidable mandatory control, edge-layer offline closed-loop execution, and omnichannel data fusion. This has resolved the long-standing technical contradictions in existing technologies, namely, the irreconcilable contradictions between access control and cloud load, evidence storage compliance and execution efficiency, and offline control and compliance consistency, and has produced technical effects that those skilled in the art could not have foreseen. Attached Figure Description

[0050] This specification contains six accompanying drawings. All reference numerals on the drawings correspond exactly to the full text of the specification and the claims, meeting the statutory requirements of the Patent Examination Guidelines.

[0051] Figure 1 is a schematic diagram of the overall architecture of the multi-terminal management and control system based on blockchain pre-existing evidence as described in this invention (see attached figure in the abstract).

[0052] Figure 2 is a schematic diagram of the full-link instruction flow of the multi-terminal management and control method of the present invention;

[0053] Figure 3 is a schematic diagram of the data flow of the closed-loop evidence storage process described in this invention;

[0054] Figure 4 is a schematic diagram of the multi-node distributed deployment architecture described in this invention;

[0055] Figure 5 is a schematic diagram of the full-link processing flow of health data according to the present invention;

[0056] Figure 6 is a schematic diagram of the multi-entity adaptation and omni-channel integration architecture described in this invention.

[0057] Appendix Label Reference Table:

[0058] 100 Processing unit 101-104 Permission verification node 105 Health data processing module 200 Blockchain Evidence Storage Unit 300 Use layer subunits 400 Cloud Subunit 401 Global rule configuration module 402 Enforcement control execution logic 403 Intelligent scheduling module 404 Distributed storage module 405 Load balancing module 406 Cross-system interface adaptation module 407 Omnichannel data synchronization module 408 Multi-subject adapter 500 Execution subunit 510 Edge control subunit 511 Local control module 512 Network status monitoring module 520 End-layer terminal subunit Detailed Implementation

[0059] The processing unit and the blockchain evidence storage unit described in this invention are bidirectionally coupled, forming an inseparable mandatory control architecture for the entire control process. The absence of either unit will prevent the realization of the core technical effects of this invention. The multi-terminal control system, method, storage medium, and electronic equipment described in this invention can be widely applied to various scenarios requiring multi-node distributed device control and trusted evidence storage throughout the entire process, such as industrial manufacturing, intelligent warehousing, and multi-site distributed services. The following detailed description, in conjunction with the accompanying drawings and embodiments, further illustrates this invention. The described embodiments are merely illustrative and do not constitute a limitation on the scope of protection of this invention.

[0060] Implementation methods of each core unit of the system.

[0061] The multi-terminal management and control system described in this embodiment is based on a core management and control architecture formed by a processing unit and a blockchain evidence storage unit. This architecture works together to form a complete management and control system of "permission verification - pre-existing evidence storage - mandatory control - closed-loop execution - full-process traceability." The specific implementation methods of each unit are as follows:

[0062] Processing Unit (100) Core Implementation Method

[0063] The processing unit (100) uses a multi-core processor and is deployed on a cloud central server or a local data center central server. It serves as the global management core of the system and is bidirectionally connected to each sub-unit and functional module via a high-speed data bus. The core execution logic is as follows:

[0064] Permission verification logic: Upon receiving a control command request, the control command is executed sequentially through a hierarchical permission verification chain formed by at least two logically independent permission verification nodes in a preset order. The control command is then subjected to full-chain hierarchical permission verification. All preceding verification nodes must be passed in a preset order. If the verification of the previous node fails, the command cannot proceed to the next verification node. If any permission node fails verification, the command is directly intercepted and cannot proceed to the subsequent process.

[0065] Pre-existing evidence storage interaction logic: The control command that completes the full-link hierarchical permission verification, along with the full-link permission verification process data, is sent to the blockchain evidence storage unit to complete the on-chain evidence storage and obtain the hash value and evidence storage verification result that are uniquely bound to all elements of the control command and the full-link verification process data.

[0066] Forced control logic: Through the built-in forced control execution logic, the on-chain evidence storage must be completed and the evidence storage verification result must be obtained before the instruction scheduling stage can be entered; the control instruction will only be scheduled and sent to the corresponding terminal for execution when the evidence storage verification result corresponding to the control instruction is received and the evidence storage verification result matches the data of the control instruction's full elements and the entire chain verification process through a unique hash value binding; instructions that fail the evidence storage verification or whose hash values ​​do not match will be intercepted and rejected for scheduling.

[0067] Closed-loop execution logic: Receive the instruction execution results returned by the terminal, send the execution result data and the entire instruction execution process data to the blockchain evidence storage unit to complete the secondary on-chain evidence storage, forming a closed loop for the entire process of control and evidence storage.

[0068] The processing unit (100) internally includes a logically decoupled application layer subunit (300), a cloud layer subunit (400), and an execution subunit (500). The three are connected bidirectionally in sequence to form a closed-loop architecture for the entire control chain. The specific implementation methods of each subunit are as follows:

[0069] Implemented using layer sub-units (300).

[0070] The layer subunit (300) is an independently split business application layer deployed on the business application server. It serves as the entry point for initiating system control commands and the feedback point for execution results. It establishes a bidirectional encrypted communication connection with the cloud layer subunit (400) through a RESTful API interface. The layer subunit (300) is configured with at least two logically independent permission verification nodes (101-104). In this embodiment, it includes four types of basic nodes: the first permission node (101), the second permission node (102), the third permission node (103), and the fourth permission node (104). The core responsibilities of each node are as follows.

[0071] First permission node (101): The entity that initiates the control instructions. It is used to receive the instruction initiation request and complete the identity authentication and basic permission verification of the initiating entity. The identity authentication adopts the account password + dynamic token two-factor authentication method. The basic permission verification includes the role permission and operation scope permission verification of the initiating entity.

[0072] Second permission node (102): For business execution entities, it is used to verify the matching of business resources and the compliance of service processes corresponding to instructions, including the availability of business resources, the completeness of service processes, and the compliance of business rules.

[0073] The third permission node (103) is for the device management entity and is used to verify the terminal device permissions corresponding to the instruction and the legality of the operation, including the online status of the target terminal, operation permissions, and device compatibility verification of the operation.

[0074] Fourth Permission Node (104): For the management entity, it has a built-in customizable compliance rule library for the final rule compliance verification of management instructions. The compliance rule library is globally configured by the cloud sub-unit and synchronized to all fourth permission nodes to ensure rule consistency. It supports real-time interception of non-compliant instructions, push of early warning information, and retention of operation logs.

[0075] Each permission verification node can be logically merged into one or more verification nodes, or split into multiple hierarchical verification nodes, depending on the regulatory level requirements of the management scenario. No modification to the underlying system architecture is required; adaptation can be completed solely through logical configuration, and the configuration takes effect in real time without requiring a system restart.

[0076] The core implementation method is as follows: using the health data processing module (105) built into the layer subunit (300).

[0077] Data Acquisition Unit: This is the upper-level entry point for the system to obtain time-series health status data. It supports multiple data source input methods, including but not limited to: Automated equipment acquisition: collecting routine non-medical health indicator data such as heart rate, blood pressure, body temperature, and body fat through smart terminals; Manual entry: supporting on-site testing and reporting by store staff and self-reporting by users; External data import: supporting transcription and entry of physical examination reports / test reports issued by hospitals and third-party medical institutions, and import of compliant external health data.

[0078] The automated equipment acquisition method does not automatically capture or directly connect to the device to collect medical-grade raw test data such as ECG, blood glucose, blood oxygen, blood oxygen saturation, and clinical biochemical indicators; medical clinical examination indicators are archived and stored only through manual entry and external report transcription. After collection, the system automatically performs data anonymization, outlier filtering, standardized format conversion, and compliant archiving to form time-series health status data corresponding to the unique identity of the service recipient.

[0079] Structured processing unit: Used to complete the standardized format conversion and compliance verification of health status data, automatically converting collected data in different formats into the system's unified JSON format, while removing outliers that exceed the normal physiological range.

[0080] Analysis Unit: Built-in difference calculation algorithm and trend analysis model, built-in linear regression algorithm, can generate health trend curves for 7 consecutive days and 30 days; can automatically complete the benchmark calculation of baseline data before intervention and retest data after intervention, generate difference results and change trends, and support longitudinal comparative analysis of multi-period data.

[0081] Visualization generation unit: Automatically generates health status time series curves and benchmarking reports based on analysis results, supports custom report templates, and the generated reports can be viewed and exported through authorized terminals.

[0082] Time-series data storage unit: Using the unique identifier of the service object as an index, it stores the full amount of health status data in chronological order to form a time-series health database. All data is synchronized to the blockchain notarization unit to complete on-chain notarization.

[0083] Implementation of Cloud Subunit (400)

[0084] The cloud layer sub-unit (400) is deployed on the cloud central server or the local data center central server. It serves as the global management and control center of the system and has built-in forced management and control execution logic (402). It can also be configured with a global rule configuration module (401), an intelligent scheduling module (403), a distributed storage module (404), a load balancing module (405), a cross-system interface adaptation module (406), an all-channel data synchronization module (407), and a multi-subject adaptation unit (408).

[0085] Global rule configuration module (401): Used to configure global business rules, access control rules, and compliance verification rules, and can synchronously distribute the rules to the edge layer control sub-unit (510) to ensure the consistency of global rules.

[0086] Forced control execution logic (402): Used to solidify the preset forced control rules, verify the evidence verification results and hash values, and intercept instructions that fail the evidence verification or whose hash values ​​do not match, so as to ensure that the rule of "first evidence, then execution" cannot be bypassed.

[0087] Intelligent scheduling module (403): Used to receive control instructions that have passed the evidence verification, send the instructions to the corresponding execution subunit (500), and receive the execution results returned by the execution subunit (500) and synchronize them to the user layer subunit (300) and the blockchain evidence storage unit (200).

[0088] Distributed storage module (404): Used for unified storage and management of global control data, equipment operation data, and business process data.

[0089] Load balancing module (405): Used to monitor the running status of the terminal cluster, the CPU load, memory usage, network status and management task volume of each side layer management sub-unit (510) in real time, and dynamically allocate management tasks and scheduling resources; when the load of a certain side layer node exceeds the preset threshold (default CPU utilization rate 80%), it automatically allocates some management tasks to adjacent nodes with loads below the threshold, and supports the automatic registration and inclusion of new nodes into the scheduling system to achieve seamless horizontal expansion of the system.

[0090] Cross-system interface adaptation module (406): It has a built-in multi-protocol adaptation unit, a national cryptographic encryption transmission unit, and a data consistency verification unit. The multi-protocol adaptation unit supports mainstream interface protocols such as HTTP / HTTPS, WebService, and SDK, and can achieve seamless integration with third-party heterogeneous business systems. The national cryptographic encryption transmission unit uses the national cryptographic SM2 / SM4 algorithm to perform end-to-end encrypted transmission of interactive data to ensure data transmission security. The data consistency verification unit supports two modes: incremental real-time synchronization and full timed verification. It automatically completes the completion and correction of differential data to ensure data consistency between the two sides.

[0091] Omnichannel data synchronization module (407): Used to realize real-time synchronization of omnichannel data between offline business nodes and online service ports. Based on the unique identity of the service object, it realizes the unified mapping of omnichannel transaction data, service data and identity data. No matter whether the service object generates business data through offline nodes or online ports, it can be automatically matched to the corresponding unique identity and synchronized to the blockchain storage unit to complete the on-chain storage, ensuring the consistency and traceability of omnichannel data.

[0092] Multi-subject adaptation unit (408): Used to implement hierarchical permission configuration and access control for different authorized subjects. It supports setting independent role permissions, data access scope and operation boundaries for different subjects. It can adapt to access of different types of authorized subjects such as directly operated subjects, franchise subjects and cross-industry cooperative subjects. No need to modify the underlying system architecture, subject access and permission configuration can be completed through visual configuration.

[0093] Implementation of the execution subunit (500).

[0094] The execution subunit (500) includes a two-way communication connection between the edge layer control subunit (510) and the end layer terminal subunit (520). The edge layer control subunit (510) and the cloud layer subunit (400) are connected in two-way communication and are the final execution carrier of control instructions and the source of field data collection.

[0095] Implementation method of edge layer control subunit (510):

[0096] The edge layer control subunit (510) is deployed on edge gateway devices in service sites, factories, parks, and other locations. It serves as the core of edge computing and local control, and includes a local control module (511), a network status monitoring module (512), a data preprocessing module, and a local rule matching module.

[0097] Local control module (511): Built-in offline permission verification rules and instruction cache library synchronized with the cloud. The offline permission verification rules are consistent with the global permission rules issued by the cloud sub-unit (400). The instruction cache library is used to cache control instructions and execution result data in the offline state, and is used for local independent control when the network is interrupted, so as to ensure that the control process in the offline state is completely consistent with the online state.

[0098] Network status monitoring module (512): Used to monitor the network connectivity status between the edge layer management subunit (510) and the cloud layer subunit (400) in real time. It sends a heartbeat packet every 500ms. When there is no response to 3 consecutive heartbeat packets, the system is immediately triggered to switch to offline management mode. When the heartbeat packet is detected to be normal and the network is connected, the system is triggered to resume interrupted transmission and full-link data synchronization operation.

[0099] Data preprocessing module: used to perform local preprocessing on the raw data collected by the end-layer terminal subunit (520), filter invalid data and synchronize it to the cloud subunit (400) to reduce cloud computing pressure and network transmission bandwidth usage;

[0100] Local rule matching module: used to load local control rules issued by cloud sub-unit (400), perform local rule matching on control instructions and forward them to end-layer terminal sub-unit (520) for execution.

[0101] Implementation method of terminal subunit (520):

[0102] The end-layer terminal subunit (520) is a field-controlled intelligent terminal. It establishes a two-way encrypted communication connection with the edge-layer control subunit (510) using standardized encrypted communication protocols (including MQTT, Modbus, and TCP / IP protocols) and synchronously completes two-way identity verification. Only terminals that pass identity verification can access the control system, ensuring the security of device access. The end-layer terminal subunit (520) is selected from one or more of the following: industrial control terminals, intelligent warehousing terminals, and non-medical health service intelligent terminals. It can flexibly access corresponding types of terminal devices according to application scenarios without modifying the core system architecture. Specifically, it includes pharmacy business terminals, health station service terminals, and health service center management terminals. Each terminal corresponds to a unique device identifier and permission scope, and the terminal is bound to the execution scenario of the control command.

[0103] Implementation method of blockchain evidence storage unit (200):

[0104] The blockchain evidence storage unit (200) adopts a permissioned blockchain architecture, including two configurable modes: private chain architecture and consortium chain architecture. It establishes bidirectional communication connections with the user layer subunit (300) and cloud layer subunit (400) through the national cryptographic SM2 encryption interface. Its core function is to manage the on-chain evidence storage and anti-tampering verification of control instructions and end-to-end business data. In this embodiment, the blockchain evidence storage unit (200) uses the Practical Byzantine Fault Tolerance (PBFT) consensus mechanism as an example implementation. Those skilled in the art can replace it with other permissioned blockchain consensus algorithms such as Raft, Paxos, and DBFT to achieve the same node consensus and anti-tampering verification functions, all of which fall within the scope of this invention. The blockchain evidence storage unit in this embodiment supports the national cryptographic SM2 asymmetric encryption algorithm and the SM3 hash algorithm. Its core execution logic is as follows:

[0105] Pre-existing evidence storage logic: Receives control instructions and full-process verification data from the layer subunit (300) to complete the full-link hierarchical permission verification. The data is stored on the blockchain through the on-chain evidence storage module. The on-chain evidence storage content includes the initiating entity information of the control instruction, the full-link permission verification process data, the core content of the instruction, the initiation timestamp, and the target execution object information. After the evidence storage is completed, a unique evidence storage hash value and the evidence storage verification pass / fail result are generated and synchronously transmitted to the cloud layer subunit (400) for mandatory control execution logic. The evidence storage hash value and the full elements of the control instruction and the full-link verification process data are uniquely bound through a cryptographic hash algorithm to ensure that the instruction and the evidence storage result correspond one-to-one.

[0106] Full-service data storage logic: On-chain storage of service object unique identifiers, health status time-series data, and omnichannel transaction event data establishes a mapping relationship between service object unique identifiers and all business data, ensuring full-chain data traceability.

[0107] Secondary evidence storage closed-loop logic: After the execution subunit (500) completes the execution of the control command, the generated execution result data and the entire process data of command execution are sent back to the user subunit (300). The blockchain evidence storage unit (200) performs secondary on-chain evidence storage on the execution result data and the entire process data of command execution. During the secondary evidence storage, the matching of the on-chain execution result data with the original control command is checked simultaneously. The check content includes the execution subject, execution operation, execution time, and consistency of execution result with the original command. Only after the check is passed can the evidence storage be completed, forming a closed-loop evidence storage for the entire control process.

[0108] Architecture adaptation logic: When configured as a consortium blockchain architecture, preset node admission rules and node read / write permission rules are set, and only nodes that have completed admission authorization can participate in on-chain data consensus and evidence verification; when configured as a private blockchain architecture, it is adapted to single-entity multi-terminal management scenarios and preset hierarchical management rules for internal authorized nodes are set.

[0109] Implementation methods for multi-terminal management and control:

[0110] The multi-terminal management method described in this embodiment, applied to any of the systems described above, specifically includes the following steps:

[0111] S1 receives a control command request and performs full-link hierarchical permission verification on the control command through a hierarchical permission verification link formed by at least two logically independent permission verification nodes, which are executed sequentially in a preset order. All preceding verification nodes must be passed in a preset order. If the verification of the previous node fails, the next verification node cannot be entered. If the verification of any permission node fails, the command is directly intercepted.

[0112] S2 will complete the control instructions for full-link hierarchical permission verification, and send them along with the full-link permission verification process data to the blockchain evidence storage unit to complete on-chain evidence storage, and obtain the hash value and evidence storage verification result that are uniquely bound to all elements of the control instructions and the full-link verification process data.

[0113] S3 executes control based on its built-in mandatory control logic: the instruction scheduling stage can only be entered after the on-chain evidence storage is completed and the evidence storage verification result is obtained. The control instruction will only be scheduled and sent to the corresponding terminal for execution when the evidence storage verification result corresponding to the control instruction is received and the evidence storage verification result matches the data of the control instruction's full elements and the entire chain verification process through a unique hash value binding. Instructions that fail the evidence storage verification or whose hash values ​​do not match will be intercepted and rejected for scheduling.

[0114] S4 receives the instruction execution results from the terminal, sends the execution result data and the entire instruction execution process data to the blockchain evidence storage unit to complete the secondary on-chain evidence storage, forming a closed loop for the entire process of control and evidence storage.

[0115] Furthermore, in step S1, each permission verification node can be logically merged into one or more verification nodes, or split into multiple step-by-step verification nodes, according to the regulatory level requirements of the control scenario.

[0116] Furthermore, step S3 also includes: if the edge layer control subunit detects a network interruption with the cloud layer subunit through the network status monitoring module, it immediately triggers the offline control mode, completes the local permission verification, local execution and data caching of the control command through the local control module, and after the network is restored, transmits the cached offline execution data to the blockchain evidence storage unit for integrity verification, and completes the full-link data synchronization after the verification is passed.

[0117] Storage media and electronic devices implementation methods:

[0118] This embodiment provides a non-transitory tangible computer-readable storage medium storing a computer program. When executed by a processor, this computer program implements all the steps of the aforementioned multi-terminal control method. The computer-readable storage medium includes tangible media capable of storing computer program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, and optical disks, but does not include transient propagation signals.

[0119] This embodiment also provides an electronic device, including a processor and a memory. The memory stores a computer program that can run on the processor. When the processor executes the computer program, it implements all the steps of the above-described multi-terminal management method and / or runs any of the multi-terminal management systems described above. The electronic device includes devices with data processing and program execution capabilities, such as industrial control computers, cloud servers, edge gateways, and smart terminals.

[0120] Typical scenario implementation example:

[0121] Example: Multi-terminal end-to-end management and control application in a multi-site health service chain scenario.

[0122] This embodiment is used to illustrate the specific application of the present invention in a scenario of unified management and control of distributed services and multiple terminals at multiple sites such as health service centers, pharmacies, and health stations, and does not constitute a limitation on the scope of protection of the present invention.

[0123] Scenario and Deployment Configuration: This example was tested in 1 provincial health service center, 3 regional health service centers, 12 community pharmacies, and 8 community health stations. The deployment configuration is as follows:

[0124] Processing Unit: Deployed on the central server in the headquarters' local data center, configured with dual-machine hot standby, and includes a user layer subunit, a cloud layer subunit, and an execution subunit. The cloud layer subunit is configured with a load balancing module, a global rule configuration module, an intelligent scheduling module, and a distributed storage module.

[0125] Execution Subunit: Each service site deploys one edge-layer control subunit (edge ​​gateway). All end-layer terminal subunits within the site are connected to the corresponding edge-layer control subunit. End-layer terminal subunits include pharmacy business terminals, health station service terminals, health service center management terminals, non-medical health service equipment, smart warehousing terminals, and cashier terminals. The edge-layer control subunit and the end-layer terminal subunits communicate using the MQTT encrypted protocol to complete two-way identity verification.

[0126] Using layered sub-units: deploy 4 types of permission verification nodes, namely the first permission node (front-end interaction terminal), the second permission node (site server terminal), the third permission node (regional center management terminal), and the fourth permission node (headquarters control backend). The fourth permission node has a built-in medical and health industry control rule library, which is uniformly configured and synchronized by the headquarters.

[0127] Blockchain Evidence Storage Unit: Configured as a consortium blockchain architecture, it sets up four types of consensus nodes: headquarters control nodes, regional service center nodes, pharmacy / station nodes, and third-party audit nodes. It presets node access rules and read / write permission rules, and only authorized nodes can participate in on-chain consensus and evidence storage verification.

[0128] Implementation Process: Pharmacy staff initiate prescription drug sales approval and control commands through the pharmacy business terminal. These commands are sequentially executed through the pharmacy manager node, the regional health service center compliance officer node, and the headquarters medical insurance management node, completing a step-by-step chain of permission verification and rule compliance confirmation in a preset order. Commands that pass verification, along with all verification process data, are pre-stored on the blockchain for evidence. The cloud-layer subunit verifies the evidence and confirms that the hash value matches all elements of the control command and the data from the entire verification process. The command is then dispatched to the edge-layer control subunit and forwarded to the corresponding terminal for execution. When the network status monitoring module detects a network interruption, the system automatically switches to offline control mode. The edge-layer control subunit completes local permission verification and execution of the command through the local control module, caching the data in the local command cache. After network recovery, the cached offline execution data passes the integrity verification by the blockchain evidence storage unit, completing full-link data synchronization. After command execution, the execution result data and the entire command execution process data are sent back to the user-layer subunit, where the blockchain evidence storage unit completes a second on-chain evidence storage, forming a closed loop for the entire control process.

[0129] Implementation Results: This embodiment has been running stably for 30 consecutive days, with a command response latency of ≤50ms, zero interruption of device management in the absence of network, offline data synchronization consistency of 99.99%, and full traceability of the management process, fully meeting the strong supervision and compliance management requirements of health service chain scenarios.

[0130] The above are merely embodiments of the present invention and are not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the present invention should be included within the scope of the claims of the present invention.

Claims

1. A multi-terminal management and control system based on blockchain-based pre-existing evidence storage, characterized in that, It includes a two-way communication coupled processing unit and a blockchain evidence storage unit, which together constitute an inseparable mandatory control architecture for the entire control process. Complete control cannot be achieved if either unit is missing. After receiving a control instruction request, the processing unit must complete the full-link verification through a hierarchical permission verification link formed by at least two logically independent permission verification nodes. If any node fails verification, the instruction will be directly intercepted. Only control instructions that have completed the full-link verification can be synchronized to the blockchain evidence storage unit. The blockchain evidence storage unit performs tamper-proof on-chain evidence storage of the received control instructions and end-to-end verification process data, generates a uniquely bound hash value, and feeds back the evidence storage verification result to the processing unit in real time. The processing unit has built-in unbypassable mandatory control execution logic, and can only issue instructions to the terminal for execution when the evidence storage verification is passed and the hash value matches. Instructions that fail the verification are all intercepted. After receiving the execution result from the terminal, the processing unit must synchronize the execution result and all process data to the blockchain evidence storage unit to complete the secondary on-chain evidence storage, forming a unique evidence storage closed loop for the entire control process.

2. The multi-terminal management and control system based on blockchain pre-existing evidence storage as described in claim 1, characterized in that, The forced control execution logic built into the processing unit is a fixed logic, which cannot be changed or bypassed through unauthorized configuration modifications, background operations, program interface calls, or unauthorized firmware upgrades. Compliance logic iteration can only be completed through a pre-defined smart contract upgrade process involving multiple nodes jointly authorized.

3. The multi-terminal management and control system based on blockchain pre-existing evidence storage according to claim 2, characterized in that, The mandatory control execution logic is solidified and deployed through a blockchain smart contract. Once deployed, the core execution logic of the smart contract cannot be modified. The deployment and upgrade of the smart contract require verification through pre-set multi-node joint authorization. A single node cannot modify the contract.

4. The multi-terminal management and control system based on blockchain pre-existing evidence storage as described in claim 1, characterized in that, The processing unit includes a logically decoupled application layer subunit, cloud layer subunit, and execution subunit. The application layer subunit, cloud layer subunit, and execution subunit are sequentially connected bidirectionally to form a closed-loop architecture for the entire control chain. The application layer subunit has a built-in permission verification node for initiating control commands and performing hierarchical permission verification. The cloud layer subunit has a built-in forced control execution logic for verifying and scheduling control commands. The execution subunit receives and executes control commands and sends the execution results back to the processing unit.

5. The multi-terminal management and control system based on blockchain pre-existing evidence storage according to claim 4, characterized in that, The execution subunit includes a side-layer control subunit and an end-layer terminal subunit with bidirectional communication connection. The side-layer control subunit and the cloud subunit are bidirectionally connected and used to complete cloud command forwarding and edge-side preprocessing. The end-layer terminal subunit is the final execution carrier of the control commands.

6. The multi-terminal management and control system based on blockchain pre-existing evidence storage according to claim 1, characterized in that, The permission verification nodes include a first permission node, a second permission node, a third permission node, and a fourth permission node; each permission verification node can be logically merged into one or more verification nodes, or split into multiple step-by-step verification nodes, according to the regulatory level requirements of the control scenario.

7. The multi-terminal management and control system based on blockchain pre-existing evidence storage according to claim 6, characterized in that, The last-level node of the permission verification node has a built-in customizable compliance rule library. The compliance rule library is used to verify the rule compliance of control instructions and to trigger interception operations and warning prompts for control instructions that do not comply with preset rules. The compliance rule base is configured globally and synchronized to all last-level permission nodes.

8. The multi-terminal management and control system based on blockchain pre-existing evidence storage according to claim 1, characterized in that, The blockchain evidence storage unit is built on a consortium blockchain or private blockchain network. It uses the national cryptographic SM3 algorithm or SHA-256 algorithm to calculate all elements of the control command and generate a hash value that is uniquely bound to the control command. The evidence storage verification result includes evidence integrity conclusion, command consistency conclusion, consensus validity conclusion, block identifier, and on-chain timestamp information.

9. The multi-terminal management and control system based on blockchain pre-existing evidence storage according to claim 1, characterized in that, The processing unit has built-in repeated trigger interception logic. For the same control instruction, the same service object and the same type of rights, after completing the rights calculation and status solidification, it automatically identifies and intercepts all subsequent requests of the same type.

10. The multi-terminal management and control system based on blockchain pre-existing evidence storage according to claim 5, characterized in that, The edge-layer control subunit has a built-in local control module and a network status monitoring module. The local control module has a built-in offline permission verification rule and instruction cache library that is synchronized globally. It is used to complete the local independent control of control instructions and data caching when the network is interrupted. The network status monitoring module is used to monitor the network connectivity status in real time, trigger the switching of the network outage control mode and the interruption resume and data synchronization operations after the network is restored. When synchronizing data after the network is restored, the integrity of the cached offline execution data needs to be verified by the blockchain notarization unit. Only after the verification is passed can the full-link data synchronization be completed.

11. The multi-terminal management and control system based on blockchain pre-existing evidence storage according to claim 4, characterized in that, The cloud subunit also includes at least one of the following: a global rule configuration module, an intelligent scheduling module, a distributed storage module, a load balancing module, a cross-system interface adaptation module, an omnichannel data synchronization module, and a multi-subject adaptation unit.

12. The multi-terminal management and control system based on blockchain pre-existing evidence storage according to claim 11, characterized in that, The cross-system interface adaptation module has a built-in multi-protocol adaptation unit, a national cryptographic encryption transmission unit, and a data consistency verification unit, which are used to realize standardized encrypted data interaction and consistency verification with third-party heterogeneous business systems; the omnichannel data synchronization module is used to realize omnichannel data real-time synchronization and unique identifier mapping between offline business nodes and online service ports.

13. The multi-terminal management and control system based on blockchain pre-existing evidence storage according to claim 11, characterized in that, The multi-subject adaptation unit is used to implement hierarchical permission configuration and access control for different authorized subjects, and supports setting independent role permissions, data access scope, and operation boundaries for different subjects.

14. The multi-terminal management and control system based on blockchain pre-existing evidence storage according to claim 1, characterized in that, The processing unit also has a built-in health data processing module, which is used to complete the standardized processing of health status data and the full-process access control. The health data processing module includes a data acquisition unit, a structured processing unit, an analysis unit, a visualization generation unit, and a time-series data storage unit. The blockchain notarization unit is also used to perform chain-based notarization of the unique identity of the service object, the time-series health status data, and the transaction event data of all channels.

15. The multi-terminal management and control system based on blockchain pre-existing evidence storage according to claim 5, characterized in that, The terminal sub-unit includes various business terminals, service terminals, and management terminals. Each terminal corresponds to a unique device identifier and permission scope, and each terminal is bound to the execution scenario of the control command.

16. A multi-terminal management method based on blockchain-based pre-existing evidence storage, characterized in that, The system applied to any one of claims 1 to 15 includes the following inseparable closed-loop execution steps: S1 receives control instructions and initiates requests. It completes full-link verification through a hierarchical permission verification link formed by at least two logically independent permission verification nodes. If any node fails verification, the instruction is directly intercepted. Only control instructions that have completed full-link verification can enter the evidence storage stage. S2 performs tamper-proof on-chain storage of verified control commands and end-to-end verification process data, generating a hash value uniquely bound to the data and the storage verification result; S3 executes control based on built-in, unbypassable mandatory control execution logic: control commands can only be issued to the corresponding terminal for execution when the evidence verification passes and the hash value completely matches the original control command and the data of the full-link verification process; commands that fail the verification will be blocked. S4 receives the instruction execution results from the terminal, synchronizes the execution results and all process data to the blockchain evidence storage unit to complete the secondary on-chain evidence storage, forming a unique evidence storage closed loop for the entire control process.

17. A non-transitory tangible computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the steps of the multi-terminal management method based on blockchain pre-existing evidence as described in claim 16.

18. An electronic device, characterized in that, It includes a processor and a memory, the memory storing a computer program that can run on the processor, and when the processor executes the computer program, it implements the multi-terminal management method based on blockchain pre-existing evidence as described in claim 16, and / or runs the multi-terminal management system based on blockchain pre-existing evidence as described in any one of claims 1 to 15.

Images