Unified access and intelligent linkage control method and device for heterogeneous security and protection system

Abstract

The invention discloses a unified access and intelligent linkage control method and device for heterogeneous security and protection systems, and belongs to the technical field of integration of the Internet of Things and intelligent security and protection systems. The method comprises the following steps: collecting and analyzing multi-protocol equipment data through an edge adapter to generate intermediate data; semantic mapping and fusion are carried out based on an equipment digital twinning model, and standardized semantic data are obtained through conversion; matching or generating an optimal linkage strategy according to events and contexts by using an intention-driven strategy library; the strategy is deduced and optimized in the virtual simulation environment, and a reliable control scheme is formed; finally, the decomposition instruction is issued and executed, and feedback is collected to form a closed loop. The device comprises a protocol translation and twinning subsystem, a strategy library construction subsystem, a simulation pre-verification subsystem and a cooperative control and feedback subsystem. According to the method, the problems of non-uniform access semantics, rigid linkage strategy and lack of pre-execution verification of heterogeneous equipment are solved, and low-cost deep integration and intelligent and reliable automatic linkage are realized.

Description

Technical Field

[0001] The present invention relates to the technical field of the integration of the Internet of Things and intelligent security systems, and particularly to a method and device for unified access and intelligent linkage control of heterogeneous security systems. Background Art

[0002] The intelligent security system is developing towards the direction of deep integration of multiple systems and intelligent collaboration, covering multiple subsystems such as video surveillance, intrusion alarm, and access control. However, these systems are often independently constructed by different manufacturers, using private protocols and data formats, forming "information islands", and it is difficult to achieve data interconnection and global intelligent linkage.

[0003] Existing technologies have tried to solve this problem, but each has its limitations. For example, CN114025139A constructs an integrated system by unified TCP / IP protocol, but has poor compatibility with legacy devices using non-IP protocols and low intelligent degree of linkage. CN114866861A uses an edge access unit to achieve protocol adaptation, but does not solve the problem of semantic unification at the platform layer, and a large amount of customization is still required for cross-system service integration. CN117221249A focuses on the management of device access identifiers and does not deeply involve cross-system semantic fusion and intelligent service linkage. CN120342896A and CN121256442A introduce advanced analysis technologies such as large models and GIS, but their effective operation depends on the premise that the underlying data has been completed with standardization and semantic unification, which has not been solved.

[0004] In summary, existing solutions have problems of high transformation cost or insufficient semantic fusion at the unified access level; at the intelligent linkage level, there are defects such as rigid strategies or lack of reliable pre-verification. Therefore, there is an urgent need for an innovative solution that can be compatible with heterogeneous access, achieve deep semantic fusion, and ensure the reliable execution of intelligent linkage. Summary of the Invention

[0005] To solve the technical problems existing in the prior art, the present invention provides a method for unified access and intelligent linkage control of heterogeneous security systems, including the following steps: S101, Heterogeneous data access and primary parsing on the edge side. Through an edge protocol adapter deployed in the local area network of the security partition, heterogeneous security devices are accessed, the collected raw data is subjected to protocol parsing and standardized encapsulation, and intermediate structured data objects are generated and uploaded to the central platform; S102, Semantic mapping on the platform side and digital twin status synchronization. On the central platform side, the intermediate structured data objects are mapped to the corresponding digital twins through a semantic mapping engine, the real-time status of the digital twins is updated, and status change events are generated; S103. Intent-driven linkage strategy matching and dynamic instantiation: In response to the state change event, the strategy template with the highest scenario adaptability score is matched from the adaptive linkage strategy library through the strategy matching engine and dynamically instantiated to generate a linkage task plan draft. S104. Strategy performance simulation pre-verification and dynamic optimization: Perform discrete event simulation on the draft linkage task scheme to identify potential conflicts and risks, and perform dynamic optimization through the strategy optimizer to generate the final executable control scheme. S105, Heterogeneous instruction issuance, collaborative execution and closed-loop learning: The final executable control scheme is issued to the corresponding edge protocol adapter, converted into device native protocol instructions and executed, while monitoring the execution status and performing closed-loop learning to optimize the device performance model and linkage strategy.

[0006] As a preferred embodiment of this application, in step S101, the heterogeneous data access and edge-side primary parsing includes: the edge protocol adapter instantiates a protocol driver according to a pre-configured device list, and collects device data through a query response mechanism or an event reporting mechanism; the parsed data is encapsulated into an intermediate structure data object, which contains fixed fields and extensible fields, and is uploaded to the central platform via the MQTT protocol.

[0007] As a preferred embodiment of this application, in step S102, the synchronization of platform-side semantic mapping and digital twin state includes: creating a digital twin for the physical device through a digital twin model management service, wherein the digital twin includes spatial attributes, functional attributes, and relational attributes; the semantic mapping engine queries mapping rules according to device identifier and protocol type, converts the original data into semantic attribute values, and updates the state of the digital twin; state change events are published to the platform's internal event bus and persistently stored in a time-series database.

[0008] As a preferred embodiment of this application, in step S103, the intent-driven linkage strategy matching and dynamic instantiation includes: the strategy templates in the linkage strategy library include linkage intents, context constraints, and dynamic execution path templates; the strategy matching engine calculates the scenario adaptability score of the strategy templates based on the characteristics of state change events and the global context, and selects high-scoring templates for instantiation; during the instantiation process, the abstract execution path is bound to specific devices and parameters through the workflow instantiator to generate a draft linkage task plan.

[0009] As a preferred embodiment of this application, in step S104, the strategy performance simulation pre-verification and dynamic optimization includes: extracting historical performance data of the device and network status through a simulation model builder to construct a lightweight discrete event simulation model; the discrete event simulation engine simulates the instruction execution process, and the conflict and risk detector identifies resource contention, deadlock, and timing violations; the strategy optimizer optimizes the draft scheme based on the simulation report and generates the final executable control scheme through iterative simulation.

[0010] As a preferred embodiment of this application, in step S105, the heterogeneous instruction issuance, collaborative execution, and closed-loop learning steps include: the edge protocol adapter translating the platform instructions into device native protocol messages and sending them to the physical device; the execution monitor comparing the expected state with the actual state, and triggering exception handling if a deviation occurs; and closed-loop learning analyzing the execution deviation and updating the device performance model and linkage strategy library.

[0011] As a preferred embodiment of this application, the dynamic instantiation in step S103 specifically includes: Parse the abstract resource references in the strategy template to determine the required target device type and functional constraints; Based on the real-time contextual knowledge graph, query the set of target physical devices that meet the functional constraints and are in an idle or low-priority state. If there are multiple target devices that meet the conditions, a specific execution device is selected from the set of target physical devices based on a load balancing algorithm or the principle of spatial proximity. The specific execution device identifier and operating parameters are bound to the action node of the strategy template to generate a draft linkage task plan containing the specific execution path.

[0012] As a preferred embodiment of this application, the dynamic instantiation in step S103 specifically includes: Parse the abstract resource references in the strategy template to determine the required target device type and functional constraints; Based on the real-time contextual knowledge graph, query the set of target physical devices that meet the functional constraints and are in an idle or low-priority state. If there are multiple target devices that meet the conditions, a specific execution device is selected from the set of target physical devices based on a load balancing algorithm or the principle of spatial proximity. The specific execution device identifier and operating parameters are bound to the action node of the strategy template to generate a draft linkage task plan containing the specific execution path.

[0013] This application also provides a unified access and intelligent linkage control device for heterogeneous security systems, used to implement the method described above. The device adopts a cloud-edge collaborative distributed architecture, including: The protocol translation and digital twin subsystem is used to achieve unified access, data parsing, and semantic mapping of heterogeneous security devices, and to manage the state of the digital twin; the protocol translation and digital twin subsystem includes a protocol adapter and a semantic mapping engine.

[0014] The strategy management and decision-making subsystem is used for matching, instantiating, and deciding on linkage strategies based on digital twin state events; the strategy management and decision-making subsystem includes a strategy library management service, a context-aware computing service, and a strategy matching and instantiation engine.

[0015] The simulation pre-verification subsystem is used to perform simulation pre-verification and dynamic optimization of the linkage schemes generated by the decision; the simulation pre-verification subsystem includes simulation model construction service, discrete event simulation engine and strategy optimization service.

[0016] The collaborative control and learning subsystem is used to execute optimized control instructions and monitor the execution effect to achieve closed-loop learning; the collaborative control and learning subsystem includes instruction orchestration and distribution services, and execution monitoring and feedback aggregation services.

[0017] Compared with the prior art, the beneficial effects of the present invention are as follows: 1) Achieved deep semantic unification and low-cost access: Adopted a two-level architecture of "edge parsing + platform twin mapping", while being compatible with existing systems, it achieves deep semanticization of data through digital twin models, overcoming the problems of high transformation costs or shallow semantic understanding of traditional solutions.

[0018] 2) Provides a flexible and intelligent linkage mechanism: Through the "intent-driven adaptive strategy library", the linkage is upgraded from fixed rules to target-driven, which can dynamically match and generate strategies according to the real-time context, significantly improving the level of intelligence in dealing with complex scenarios.

[0019] 3) Execution reliability is ensured through simulation pre-verification: The unique virtual simulation stage before strategy execution can detect and avoid resource conflicts and timing risks in advance, ensuring reliable execution of linkage in complex heterogeneous environments.

[0020] 4) Possesses closed-loop learning and continuous optimization capabilities: By executing feedback-driven device model correction and strategy optimization, the system has the ability to continuously learn and evolve from actual operation, achieving intelligent improvement and reliability growth under long-term operation. Attached Figure Description

[0021] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0022] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 This is a general flowchart of the unified access and intelligent linkage control method provided in the embodiments of the present invention.

[0024] Figure 2 This is a schematic diagram of heterogeneous data access and edge-side primary parsing provided in an embodiment of the present invention.

[0025] Figure 3 This is a schematic diagram of platform-side semantic mapping and digital twin state synchronization provided in an embodiment of the present invention.

[0026] Figure 4 This is a schematic diagram of the linkage strategy matching and dynamic instantiation provided in the embodiments of the present invention.

[0027] Figure 5 This is a schematic diagram of strategy performance simulation pre-verification and dynamic optimization provided in the embodiments of the present invention.

[0028] Figure 6 This is a schematic diagram of heterogeneous instruction issuance, collaborative execution, and closed-loop learning provided in an embodiment of the present invention.

[0029] Figure 7 This is the overall architecture diagram of the unified access and intelligent linkage control device provided in the embodiments of the present invention. Detailed Implementation

[0030] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0031] It should be noted that all directional indications (such as up, down, left, right, front, back, etc.) in the embodiments of the present invention are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indication will also change accordingly.

[0032] Furthermore, the use of terms such as "first" and "second" in this invention is for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, features defined with "first" and "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of the various embodiments can be combined with each other, but only on the basis of being achievable by those skilled in the art. When the combination of technical solutions is contradictory or impossible to implement, such a combination of technical solutions should be considered non-existent and not within the scope of protection claimed by this invention.

[0033] Example 1 This invention provides a unified access and intelligent linkage control method for heterogeneous security systems. Its core process is an intelligent closed loop encompassing "perception-mapping-decision-simulation-execution-feedback." For example... Figure 1 As shown, the specific steps are as follows: S101, Heterogeneous Data Access and Edge-Side Primary Resolution This step aims to physically connect various heterogeneous security devices and complete preliminary data structuring. For example... Figure 2 As shown, the specific implementation is as follows: First, deploy one or more edge protocol adapters within the local area network of the security zone (such as a single building, floor, or specific functional area) where data collection is required. An edge protocol adapter is a hardware device or a software module deployed on an edge server gateway. Each edge protocol adapter contains or loads a dynamically updatable protocol driver library. The protocol driver library includes parsing drivers for a range of communication protocols, including BACnet / IP, Modbus RTU, Modbus TCP, OPC UA, ONVIF, GB / T28181, and proprietary protocols of common brand access control controllers. Its update mechanism supports unified distribution of update packages through a central platform or retrieval from a designated server via a secure connection, enabling scalable support for new protocols. Each parsing driver is responsible for communicating with devices using one or a class of specific protocols.

[0034] Once the edge protocol adapter starts, its driver management module instantiates the corresponding protocol driver for each device to be connected, based on a pre-configured device list. The edge protocol adapter collects data in parallel through two mechanisms: 1) For protocols that support query responses (such as Modbus, some private serial port protocols, etc.), the scheduler within the edge protocol adapter, with configurable priorities, periodically triggers the protocol driver, causing it to send data request frames to the target device according to a preset register address table or object identifier list. When high-priority event data arrives, the scheduler can pause or delay the periodic query task to ensure real-time event response. The protocol driver then receives the response frame returned by the target device and extracts valid values ​​or status codes from the raw byte stream by calling the protocol's specific decoding function library. 2) For protocols that support event reporting or streaming (such as ONVIF events, GB / T28181 alarm notifications, BACnet COV subscriptions, etc.), the edge protocol adapter switches to listening mode. The protocol driver subscribes to key event topics (such as motion detection, video loss, etc.) or establishes media streaming sessions with the target device and continuously listens to the specified network port. When a key frame is captured in a data packet (data stream) actively reported by the target device, the protocol driver immediately activates the parsing logic to extract the event type, timestamp, and associated parameters.

[0035] After parsing, the results generated by the protocol driver are sent to a structured encapsulation module. This module organizes and encapsulates data from different protocols and formats into a standardized intermediate data object. This intermediate data object contains a set of fixed and expandable fields. Fixed fields include, but are not limited to: adapter unique identifier, original device identifier (such as IP address, serial port address, device serial number, etc.), data acquisition timestamp, protocol type, and original data type (such as register value, alarm event, etc.). Expandable fields carry specific numerical values ​​or states. The internal structure of expandable fields dynamically changes according to the original data type, and their format follows a predefined JSON Schema template on the platform side, ensuring the self-descriptive nature and parsing consistency of the data structure. For example, the load of an analog input point might be {address: 40001, value: 23.5, unit: °C}, while the load of a door magnetic alarm event might be {event code: 0x0A, area: main entrance, description: door is open}.

[0036] Finally, the edge protocol adapter's secure communication module mainly uses the MQTT protocol (which can also be configured as an HTTPS / REST API as needed) to upload the encapsulated intermediate structure data objects to the central platform's message middleware (such as Kafka, RabbitMQ, etc.) in real time or in batches.

[0037] S102, Platform-side semantic mapping and digital twin state synchronization This step aims to assign explicit business semantics to intermediate structured data objects and associate them with virtual entities (digital twins) within the platform, thereby achieving a deep understanding and correlation of the data. For example... Figure 3 As shown, the specific implementation is as follows: A digital twin model management service runs on the central platform. During system initialization or dynamic device network access, this service creates a corresponding digital twin model for each physical entity within the platform through administrator configuration or an automatic discovery protocol. The automatic discovery protocol can be implemented based on network scanning or device registration. After discovery, it requires administrator confirmation or automatic mapping based on a predefined rule base to reduce false identifications. The digital twin model is a complex data structure that not only records device IDs but also defines the device's identity and relationships within the business world. The attributes of the digital twin model include, but are not limited to: spatial attributes based on a hierarchical spatial model (e.g., campus / building A / third floor / east corridor); device type and functional attributes inherited from a predefined security device ontology (e.g., a face recognition gate type twin automatically possesses functional attributes such as segment mode and face database ID); and descriptions of relationships with other twins (e.g., being monitored by camera CAM101 and controlling door lock LOCK205).

[0038] After the central platform's message middleware receives the intermediate structure data object reported by the edge side from the relevant topic, the semantic mapping engine is triggered. The semantic mapping engine first queries the global device registration and mapping relationship table using the source device ID and protocol type from the intermediate structure data as a composite key to accurately locate the unique identifier of the target digital twin corresponding to the data stream. Next, the semantic mapping engine loads a set of matching field semantic mapping rules based on the original data type. These semantic mapping rules are stored in a versionable database and specify how a piece of original data should be understood and transformed. For example, a rule might state: "When the device type is 'access controller' and the event code is 0x0A, this event should be mapped to the 'door status' attribute of the target twin and its value should be converted to 'door open alarm'." The semantic mapping engine executes rules to perform data type conversions, unit standardization, and annotation of key semantics. For example, it converts the original event code "0x0A" into the semantically meaningful "Door Status: Door Open Alarm". Subsequently, the semantic mapping engine calls the digital twin state management interface to write the semantically converted value to the twin's real-time state cache in an in-memory database (such as Redis), updating its current state. Simultaneously, the state management service checks the relationships defined for the twin. If a relationship is found (such as proximity or monitoring), the state management service generates an internal event to notify other related twins or services.

[0039] The complete record of all state changes (including old values, new values, and timestamps) is persistently written asynchronously to a time-series database (such as InfluxDB) for permanent archiving, and a state change event with a timestamp is generated and published to the internal event bus of the platform. The internal event bus adopts a publish-subscribe model based on topics (such as Kafka Topic), and events with different priorities can be routed to different priority message queues for processing. This announces that this original data has completed the sublimation from bit stream to business semantics and provides high-quality, associable context information for subsequent intelligent decision-making.

[0040] S103. Intent-driven linkage strategy matching and dynamic instantiation This step aims to dynamically generate an optimal linkage control sequence based on semantic events and the global state. As Figure 4 shown, the specific implementation is as follows: The platform maintains an intent-driven adaptive linkage strategy library. Each policy template in the adaptive linkage strategy library consists of three core elements: one is the linkage intent that describes the high-level business goals to be achieved by the policy (such as emergency evacuation, area blockade, evidence preservation, etc.); the second is a set of context constraints used to determine whether the policy is applicable. The context constraints are logical expressions based on multi-dimensional contexts, which can comprehensively evaluate factors such as event type, occurrence space, time window, online status of associated devices, and environmental risk level; the third is a dynamic execution path template that defines the action blueprint required to achieve the intent. The dynamic execution path template is a workflow composed of multiple atomic action nodes and their control flows (sequence, parallel, selection), and its description is defined using a standardized business process model and notation or a JSON-based domain-specific language to ensure parseability and executability.

[0041] When a high-priority state change event is published by the platform's internal event bus (e.g., the "alarm status" attribute of a twin representing a flame detector changes to "fire alarm"), the policy matching engine is triggered. The engine first performs a deep analysis of the state change event, extracting key features such as the precise spatial path, event type, and severity level of the source twin. Then, the engine concurrently traverses all templates in the adaptive linkage policy library. For each policy template, the engine performs two calculations: first, it assesses the semantic relevance between the essential characteristics of the current state change event and the policy's linkage intent; second, it substitutes the current global context snapshot (maintained in real-time by an independent context-aware service) into the policy's context constraints, calculating the satisfaction rate of all constraints. These two calculations are combined, and a scenario fit score is calculated for each policy template using a weighted scoring based on the policy's historical execution success rate and expert-preset weights. During system initialization or when there is no historical data for the policy, the expert-preset default weights are used for calculation, gradually transitioning to a weight allocation based primarily on historical data as execution cases accumulate.

[0042] The strategy matching engine selects one or more strategy templates with the highest scenario fit scores to enter the instantiation phase. Instantiation is a fill-in-the-blank process executed by the workflow instantiator. After obtaining the abstract dynamic execution path template, the workflow instantiator dynamically determines the specific parameters of each action node based on the specific parameters of the current state change event. For example, for the action "open all safety exits" in the "emergency evacuation" strategy, the workflow instantiator performs topology analysis and risk assessment in the spatial model based on the event location (such as delineating dangerous areas based on the fire spread model), dynamically calculating a list of all safety exits that need to be opened within the dangerous area; then, it queries the access control device twins corresponding to these safety exits, checks their online status and health, and automatically excludes unavailable devices from the list and records alarms if necessary; finally, it binds these specific device identifiers and control parameters to the action nodes. After instantiation, an abstract, parameterized strategy template is transformed into a specific linked task plan draft. The linked task plan draft contains clear objectives, a series of suggested action instruction sequences bound to specific devices and resources, and the expected final state.

[0043] S104, Strategy Performance Simulation Pre-verification and Dynamic Tuning This step is a critical safety barrier to ensure the reliable execution of complex linkages in the real physical world. It involves "pre-simulating" the process in a virtual environment to identify and fix potential problems. For example... Figure 5 As shown, the specific implementation is as follows: When the draft linkage task plan from S103 enters the execution queue, the simulation subsystem is triggered to start. The simulation model builder first analyzes the draft plan and extracts the twin identifiers of all involved controlled devices. Then, the simulation model builder queries the device twin subsystem for recent historical performance data (such as the past 24 hours) of these devices, and statistically analyzes the command response latency model (such as average latency, standard deviation, latency distribution, etc., the command response latency model is updated periodically with the generation of new data) and command execution success rate of each device from the time series database. For newly connected devices or devices without historical data, a default performance model based on device type or a statistical inference model based on data of similar devices is used as the initial value. At the same time, the estimated latency and packet loss rate data of each link in the current network topology are obtained through the network status monitoring service. In addition, the state dependencies and mutual exclusion rules between devices are extracted from the functional attributes and relationships of the twins (for example, a PTZ camera cannot be manually tracked while performing a preset position cruise).

[0044] The simulation model builder integrates this information to quickly construct a lightweight, discrete-event simulation model for this task. Subsequently, the discrete-event simulation engine loads this simulation model and a draft of the linked task plan. Following the action logic and timing relationships defined in the task, the discrete-event simulation engine progressively advances the simulation along the virtual timeline. The engine simulates each action: calculating the time required for the instruction to be issued from the platform, transmitted over the network to the edge adapter, the adapter to convert protocols, and finally arrive at the device; then, based on the device's response delay model, it randomly samples a delay time to simulate the device's internal processing; finally, it determines whether the action is successful or failed based on the execution success rate, and if successful, updates the device's state in the simulation environment. The entire simulation is monitored by a conflict and risk detector, which has a built-in rule base that supports dynamic expansion and allows the import of domain expert knowledge or machine learning models trained based on historical conflict data. This base is used to identify resource contention (e.g., two actions attempting to simultaneously monopolize the same device), state deadlock (e.g., action A waiting for the state of device B, while the state of device B depends on the result of action A), and timing violations (e.g., critical actions cannot be completed before the deadline).

[0045] After the simulation, the discrete event simulation engine generates a detailed deduction report, clearly identifying all conflicts, bottlenecks, and failure risk points detected during the process. The policy optimizer receives this deduction report and applies pre-defined optimization algorithms to fine-tune the original draft solution. For example, for resource conflicts, the policy optimizer may reallocate the execution priority of conflicting actions or find functionally equivalent backup equipment for replacement. For timing risks, it may adjust the execution order of actions or insert buffers on the critical path. For actions with high failure risk, backup or compensation actions will be dynamically injected (e.g., "if remote access control fails, notify on-site security to manually open it"). Optimization may be an iterative process. After the policy optimizer generates a new solution, it can trigger a rapid re-simulation verification, setting a maximum number of iterations or an optimization target threshold as the iteration termination condition, until a final executable control solution is output that has been verified, has controllable risks, and where the conflict detector reports no serious conflicts. The final executable control solution signifies the acceptance and optimization of the original draft by the simulation pre-verification stage, granting it executable status. The final executable control scheme not only includes the sequence of actions, but also the expected execution timeline and key monitoring points.

[0046] S105, Heterogeneous Instruction Deployment, Collaborative Execution and Closed-Loop Learning This step is responsible for safely and reliably implementing the virtually validated perfect solution in the imperfect real world, forming a closed loop of continuous improvement. For example... Figure 6 As shown, the specific implementation is as follows: The instruction orchestration and distribution service receives the final executable control scheme from S104. Its internal workflow engine parses the action logic within the final executable control scheme and orchestrates them into a specific execution plan. The distributor then transforms each action into a specific platform-layer control instruction object based on the target device twin identifier and distributes it to the edge protocol adapter managing the device via a reliable, two-way authenticated message channel (such as MQTT). Reliability is guaranteed through the message queue's quality of service level, end-to-end acknowledgment mechanism, and failure retransmission strategy.

[0047] The edge protocol adapter's instruction receiving module listens for platform instruction topics. Upon receiving an instruction, the edge protocol adapter queries its locally stored reverse protocol mapping table to translate the platform abstraction instruction into a native protocol message that the target physical device can understand. For example, it translates an unlock instruction into a specific Modbus command or a private TCP string. Then, the edge protocol adapter sends the raw message to the target physical device via the appropriate network or serial port.

[0048] Simultaneously, the platform's execution monitor creates a monitoring session for this collaborative task. The execution monitor synchronously listens to two feedback streams: first, instruction response receipts (ACK / NACK / Timeout) proactively reported by the edge adapter, used to determine whether the instruction has been received by the device; second, it continuously obtains the actual state changes of the relevant device twin from the semantic mapping results of S102. The execution monitor compares the actual state changes with the expected state changes of the instruction, setting a tolerance time window and a state value tolerance threshold during the comparison process to objectively verify the execution effect of the instruction.

[0049] Based on feedback, the system performs closed-loop processing. If the execution effect of the instruction is successfully verified, the action is marked as completed and the workflow is advanced. If an instruction fails or the status is inconsistent, an exception handling procedure is triggered, and its strategy may include automatic retry, switching to a backup execution path, or escalation to manual intervention. After the entire task is completed, the execution monitor generates a comprehensive execution report, which records in detail the deviation between the plan and the actual situation. Based on this report, the system performs closed-loop learning analysis. The reasons for the deviation include slower response of specific equipment at night, instability of a certain network link, etc. The system automatically identifies the causes of the deviation through time series analysis and pattern recognition algorithms and generates two types of outputs: First, it generates corrected data for the equipment twin performance model. The corrected data is incorporated into the equipment performance model through statistical algorithms (such as parameter estimation based on Bayesian updates or exponential smoothing) and fed back to the simulation model builder in S104 to make the next simulation more accurate. Second, it generates optimization suggestions for linkage strategies, such as marking the ineffectiveness of a certain strategy under certain conditions, or recommending new strategy parameters, which are then fed back to the strategy library in S103 to drive the continuous evolution of the entire system.

[0050] Example 2 This invention provides a unified access and intelligent linkage control device for heterogeneous security systems. The device adopts a cloud-edge collaborative distributed architecture, where subsystems exchange data and collaborate through well-defined service interfaces and messaging protocols. For example... Figure 7 As shown, it specifically includes: Protocol Translation and Twin Systems Protocol translation and twin subsystems form the foundation for the device's data perception and cognition, comprised of edge-layer hardware components and platform-layer software services. At the edge layer, the core is a distributed protocol adapter unit. Each adapter unit integrates multiple physical communication interfaces, such as a Gigabit Ethernet port for connecting IP cameras and controllers, an RS-485 bus interface for connecting traditional serial sensors and actuators, and a digital input / output interface for acquiring dry contact alarm signals. Internally, the adapter runs a lightweight embedded operating system, which hosts a protocol driver container. This container manages a series of protocol driver plugins, each encapsulating complete parsing and packet assembly capabilities for a specific industrial or security protocol (such as BACnet, Modbus, OPC UA). Protocol driver plugins support dynamic upgrades via update packages distributed from the platform side to expand support for new protocols. The driver management module dynamically loads and instantiates the required driver plugins based on the distributed device configuration list.

[0051] Data acquisition tasks are coordinated by a local scheduling module, which supports configurable task priorities. This allows high-priority event listening tasks to be interrupted or prioritized over periodic polling tasks, and supports periodic data acquisition from pollable devices and asynchronous listening to event-driven devices. The acquired raw byte stream is processed by the parsing function of the corresponding driver plugin and extracted into structured key-value pairs. Subsequently, the structured encapsulation module assembles these key-value pairs into intermediate data packets with uniform fields according to a predefined template. This packet is then stably transmitted to the central platform's message access gateway via the secure communication module (implementing TLS client functionality) integrated on the adapter, primarily via the MQTT protocol, through the enterprise intranet or VPN.

[0052] At the platform layer, the message access gateway is responsible for receiving and buffering data streams from a massive number of edge adapters. The device twin model library is a persistent storage based on a document database, storing static model definitions for all managed devices, including their model specifications, functional point lists, spatial affiliations, and logical associations with other devices. The semantic mapping engine, as the core processing service, continuously consumes data from the message queue. It first utilizes the device registry service to map the edge device identifier in the message to a standard twin unique identifier within the platform. Then, it queries the semantic mapping rule library, which stores conversion rules from various raw data points to twin attribute points (including data type conversion, engineering unit conversion, enumeration value translation, etc.). The engine applies these rules to convert the raw data into attribute values ​​with clear business meaning.

[0053] After the transformation is complete, the engine invokes the twin state management service to update the real-time state of the corresponding twin in the cache. While updating the state, the state management service triggers relevant event notifications based on the relationships defined in the twin model. All historical records of state changes are asynchronously written to a dedicated time-series database cluster for querying and analysis. Finally, a standardized event representing "a certain attribute of a twin has been updated" is published to the platform's distributed event stream system, providing unified, semantic state change notifications for upper-layer applications.

[0054] Strategy Management and Decision Subsystem The strategy management and decision-making subsystem is the intelligent decision-making brain of the device, deployed entirely at the platform layer. The strategy library management service offers both a graphical editing interface and a domain-specific language, allowing security experts to easily define, modify, and version-manage linked strategy templates. Each template is stored in a structured relational database, containing intent declarations, context constraint expressions, and dynamic execution path blueprints defined based on a workflow description language.

[0055] The context-aware computing service is an independent microservice that continuously subscribes to platform event streams and external data source interfaces. It integrates information from multiple sources, including real-time device twin status, meteorological information interfaces, calendaring systems, and personnel location data. Through pre-defined aggregation and inference rules, it dynamically maintains a global, multi-dimensional context knowledge graph. This graph reflects the overall situation of the entire security environment in real time.

[0056] The strategy matching and instantiation engine is the decision trigger point. It is activated when a high-priority alarm event is received from the event stream. It evaluates the applicability of templates in the strategy library in parallel. The evaluation process combines intent matching based on semantic similarity algorithms with logical evaluation by substituting the current context knowledge graph into constraint expressions. A weighted score is calculated based on the historical success rate of the strategy and pre-set weights by experts, ultimately calculating a comprehensive confidence score for each template. For one or more templates with scores exceeding a threshold, the engine initiates the instantiation process. The instantiator parses the dynamic execution path in the template. For variables and fuzzy references (such as "nearby cameras"), it queries spatial information services and device twin relationship services in real time to parse them into a specific list of device identifiers and operational parameters, thereby generating a draft of a specific linkage task plan. Historical strategy execution cases and their effect evaluations are stored in a case library, providing data support for continuous strategy optimization and case-based reasoning.

[0057] Simulation pre-verification subsystem The simulation pre-verification subsystem is the core of the device's risk management and reliability enhancement, operating as an independent service set at the platform layer. After the strategy management and decision-making subsystem generates a draft of a coordinated task plan, the simulation model building service first parses it. Based on the identifiers of all devices involved in the instance, the building service initiates batch queries to the device twin subsystem to obtain the recent (e.g., past 24 hours) historical control logs of these devices (used to build periodically updated performance models). Through log analysis, the building service fits a simplified probabilistic performance model for each device, including the distribution characteristics of command response time (e.g., the mean and variance of a normal distribution) and the success rate of command execution. Simultaneously, the network monitoring service provides a real-time network latency prediction matrix.

[0058] The discrete event simulation engine is the computational core of the subsystem. It loads performance models, network latency data, and interconnected workflow instances generated by the build service. The engine creates a virtual simulation clock and event queue, strictly following the workflow logic to advance the simulation. It simulates the complete chain of each control command from issuance, network transmission, to device processing, and finally to the generation of status feedback, introducing random latency based on the performance model and random failure based on success rate. During the simulation, the parallel-running conflict detection module checks in real time for deadlocks caused by device resource contention, action sequence issues, or operations that violate physical constraints, based on a set of predefined resource conflict rules and state machine rules.

[0059] After the simulation runs, the simulation analysis service generates a detailed report including the timeline, resource utilization, critical path analysis, and risk points. The strategy optimization service receives this report. It incorporates various optimization algorithms, such as a timing adjustment algorithm based on the critical path method and an action reordering algorithm based on a resource conflict graph. The optimization service attempts to adjust the original workflow, such as rescheduling actions on non-critical paths, inserting precondition checks for high-risk actions, or adding backup actions. For complex optimizations, multiple rapid iterative cycles of "simulation-analysis-optimization" may be required until a final executable control scheme that satisfies all reliability constraints and has no serious conflicts is generated. All simulation inputs, outputs, and optimization records are archived for subsequent training and improvement of optimization algorithms.

[0060] Cooperative Control and Learning Subsystem The collaborative control and learning subsystem acts as the device's "actuator" and "feedback nerve," spanning both the platform and edge layers to ensure the precise implementation of intelligent decisions. At the platform layer, the instruction orchestration and distribution service receives the final executable control scheme from the simulation pre-verification and optimization subsystem. Its internally integrated workflow engine parses the scheme, generating an execution plan with dependencies and timeout controls. The distribution service transforms each atomic action in the plan into a specific platform instruction and, through a reliable message middleware, precisely pushes the instructions to the target edge nodes according to the edge adapter's subscription relationships.

[0061] At the edge layer, the instruction receiving and processing module on the adapter listens for platform instruction topics. Upon receiving an instruction, this module invokes the local protocol converter. The converter queries the "instruction-protocol command mapping table," translating the platform's abstract instructions (such as "arm") into precise command frames (such as specific binary strings or XML messages) that the target device's native protocol can recognize, and then sends them out through the corresponding physical interface. The adapter also possesses basic local fault-tolerance logic; for example, in the event of a network outage, it can respond to hardwired alarm signals according to locally configured simplified rules.

[0062] The platform-layer execution monitoring and feedback aggregation service maintains a monitoring session for each executing linked task. It aggregates two types of asynchronous feedback: first, confirmation of instruction delivery proactively reported by the edge adapter and the device's original response; second, actual changes in device state indirectly obtained through the device twin subsystem and semantically mapped. The monitoring service compares the expected state with the actual state to achieve closed-loop verification. It manages an exception handling strategy library, automatically triggering corresponding processing flows, such as retry, bypass, or reporting, when instruction failure or state discrepancy is detected.

[0063] After the entire task is completed, the execution monitoring and feedback aggregation service performs a post-mortem analysis of the entire process, calculates various performance indicators, and compares them with simulation predictions. Insights derived from the analysis, such as performance degradation of specific equipment during specific periods and common failure modes of certain strategies in actual execution, are structured and recorded. These records are used, on the one hand, to dynamically adjust the performance model parameters of the equipment twin, making the simulation subsystem more realistic; on the other hand, they serve as strategy optimization suggestions, feeding them back to the strategy management and decision-making subsystem to trigger the review and optimization of strategy templates, thereby achieving continuous and automated evolution of the overall intelligence level of the device.

[0064] Example 3 The present invention also provides an electronic device, including: a processor, a transmitting device, an input device, an output device, and a memory. The processor may be implemented using a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit, or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory may be implemented using a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM), and is used to store computer program code. The computer program code includes computer instructions. When the processor executes the computer instructions, the electronic device executes a method as described in any of the above possible implementation methods.

[0065] Example 4 The present invention also provides a computer-readable storage medium storing a computer program, the computer program including program instructions, which, when executed by a processor of an electronic device, cause the processor to perform a method as described in any of the above possible implementations.

[0066] In the description of this specification, the references to terms such as "an embodiment," "example," "specific example," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0067] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for unified access and intelligent linkage control of heterogeneous security systems, characterized in that, Includes the following steps: S101, Heterogeneous Data Access and Edge-Side Primary Parsing: Through the edge protocol adapter deployed in the security zone LAN, heterogeneous security devices are accessed, the collected raw data is parsed and standardized and encapsulated, intermediate structure data objects are generated and uploaded to the central platform; S102. Platform-side semantic mapping and digital twin state synchronization: On the central platform side, the intermediate structure data object is mapped to the corresponding digital twin through the semantic mapping engine, the real-time state of the digital twin is updated, and a state change event is generated. S103. Intent-driven linkage strategy matching and dynamic instantiation: In response to the state change event, the strategy template with the highest scenario adaptability score is matched from the adaptive linkage strategy library through the strategy matching engine and dynamically instantiated to generate a linkage task plan draft. S104. Strategy performance simulation pre-verification and dynamic optimization: Perform discrete event simulation on the draft linkage task scheme to identify potential conflicts and risks, and perform dynamic optimization through the strategy optimizer to generate the final executable control scheme. S105, Heterogeneous instruction issuance, collaborative execution and closed-loop learning: The final executable control scheme is issued to the corresponding edge protocol adapter, converted into device native protocol instructions and executed, while monitoring the execution status and performing closed-loop learning to optimize the device performance model and linkage strategy.

2. The method according to claim 1, characterized in that, In step S101, the heterogeneous data access and edge-side primary parsing include: the edge protocol adapter instantiates the protocol driver according to the pre-configured device list, and collects device data through a query response mechanism or an event reporting mechanism; the parsed data is encapsulated into an intermediate structure data object, which contains fixed fields and extensible fields, and is uploaded to the central platform through the MQTT protocol.

3. The method according to claim 1, characterized in that, In step S102, the synchronization of platform-side semantic mapping and digital twin state includes: creating a digital twin for the physical device through the digital twin model management service, wherein the digital twin includes spatial attributes, functional attributes, and relational attributes; the semantic mapping engine queries the mapping rules according to the device identifier and protocol type, converts the original data into semantic attribute values, and updates the state of the digital twin; the state change event is published to the platform's internal event bus and persistently stored in the time-series database.

4. The method according to claim 1, characterized in that, In step S103, the intent-driven linkage strategy matching and dynamic instantiation includes: the strategy templates in the linkage strategy library include linkage intents, context constraints, and dynamic execution path templates; the strategy matching engine calculates the scenario adaptability score of the strategy template based on the characteristics of the state change event and the global context, and selects high-scoring templates for instantiation; during the instantiation process, the abstract execution path is bound to specific devices and parameters through the workflow instantiator to generate a draft linkage task plan.

5. The method according to claim 1, characterized in that, In step S104, the strategy performance simulation pre-verification and dynamic optimization includes: extracting historical performance data of the device and network status through the simulation model builder to construct a lightweight discrete event simulation model; the discrete event simulation engine simulates the instruction execution process, and the conflict and risk detector identifies resource contention, deadlock and timing violations; the strategy optimizer optimizes the draft scheme based on the simulation report and generates the final executable control scheme through iterative simulation.

6. The method according to claim 1, characterized in that, In step S105, the heterogeneous instruction issuance, collaborative execution, and closed-loop learning steps include: the edge protocol adapter translating the platform instructions into device native protocol messages and sending them to the physical device; the execution monitor comparing the expected state with the actual state, and triggering exception handling if a deviation occurs; and closed-loop learning analyzing the execution deviation and updating the device performance model and linkage strategy library.

7. The method according to claim 4, characterized in that, The dynamic instantiation in step S103 specifically includes: Parse the abstract resource references in the strategy template to determine the required target device type and functional constraints; Based on the real-time contextual knowledge graph, query the set of target physical devices that meet the functional constraints and are in an idle or low-priority state. If there are multiple target devices that meet the conditions, a specific execution device is selected from the set of target physical devices based on a load balancing algorithm or the principle of spatial proximity. The specific execution device identifier and operating parameters are bound to the action node of the strategy template to generate a draft linkage task plan containing the specific execution path.

8. The method according to claim 5, characterized in that, The construction of the lightweight discrete event simulation model in step S104 specifically includes: Extract historical performance data of the target device twin, including instruction response time sequence and instruction execution success rate within a preset time period in the past; Based on the command response time series, a statistical fitting algorithm is used to generate a probability distribution model of the device's command response time. Based on the success rate of the instruction execution, a binomial distribution failure model for the device is constructed. In the simulation environment, the simulation delay time is randomly sampled according to the instruction response time probability distribution model, and the simulation execution result is randomly determined according to the binomial distribution failure model, so as to simulate the nondeterministic behavior of physical devices in a real network environment.

9. A unified access and intelligent linkage control device for heterogeneous security systems, wherein the device applies the method described in any one of claims 1 to 8, characterized in that, The device adopts a cloud-edge collaborative distributed architecture, including: The protocol translation and digital twin subsystem is used to achieve unified access, data parsing and semantic mapping of heterogeneous security devices, and to manage the state of the digital twin. The strategy management and decision-making subsystem is used for matching, instantiating, and making decisions on linkage strategies based on digital twin state events; The simulation pre-verification subsystem is used to perform simulation pre-verification and dynamic optimization of the linkage schemes generated by the decision. The collaborative control and learning subsystem is used to execute optimized control commands and monitor the execution effect to achieve closed-loop learning.

10. The apparatus according to claim 9, characterized in that, The protocol translation and twin subsystem includes a protocol adapter and a semantic mapping engine; the policy management and decision-making subsystem includes a policy library management service, a context-aware computing service, and a policy matching and instantiation engine. The simulation pre-verification subsystem includes a simulation model building service, a discrete event simulation engine, and a strategy optimization service. The collaborative control and learning subsystem includes instruction orchestration and distribution services, and execution monitoring and feedback aggregation services.

Images