Campus safety situation assessment and early warning method and system based on multi-source data fusion

Abstract

This application provides a method and system for campus security situation assessment and early warning based on multi-source data fusion, relating to the field of campus security management technology. First, it collects multi-source data streams from campus video surveillance, IoT sensors, information system logs, and access control systems, parsing out security-related event fragments. Then, it matches and associates these security-related event fragments with a pre-built campus event knowledge base to construct a campus event network diagram. Based on this campus event network diagram, it drives simulation and constraint-based inference models to perform event propagation inferences. The fusion results generate a set of snapshots of inference scenarios. The snapshots are processed to generate representative future security scenarios and trace key event fragment sequences. Based on these, a set of campus security early warning and response instructions is generated. This invention can comprehensively and accurately assess the campus security situation and provide timely early warnings.

Description

Technical Field

[0001] This application relates to the field of campus safety management technology, and more specifically, to a method and system for campus safety situation assessment and early warning based on multi-source data fusion. Background Technology

[0002] Campus safety is a crucial foundation for ensuring the normal conduct of educational and teaching activities and protecting the lives and property of teachers and students. With the continuous expansion of campuses and the deepening of information technology infrastructure, a large amount of safety-related data is generated on campus, such as video surveillance data, IoT sensor data, information system log data, and access control data. However, current campus safety situation assessment and early warning mainly rely on single data sources or simple manual analysis methods.

[0003] Analysis methods based on a single data source have significant limitations. For example, relying solely on video surveillance data can only provide intuitive visual information about people and certain scenes on campus, failing to effectively identify potential security risks hidden behind the data, such as equipment malfunctions and abnormal network access. While IoT sensor data can reflect device status and environmental parameters, it lacks analysis of personnel behavior and logical relationships between events. Information system log data and access control data can only provide information on specific aspects, making it difficult to comprehensively grasp the campus security situation.

[0004] Simple manual analysis methods are not only inefficient, but also easily limited by the subjective experience and energy of the analysts. They are difficult to conduct real-time, comprehensive and in-depth analysis of massive amounts of multi-source data, and cannot detect potential security threats in a timely manner and make accurate early warnings. They are also unable to meet the high requirements of modern campus security management for real-time performance, accuracy and comprehensiveness. Summary of the Invention

[0005] In view of this, the purpose of this application is to provide a method and system for campus security situation assessment and early warning based on multi-source data fusion.

[0006] According to a first aspect of this application, a method for campus security situation assessment and early warning based on multi-source data fusion is provided, the method comprising: Collect multi-source data streams within the campus, and parse discrete security-related event fragments from the multi-source data streams in real time. The multi-source data streams include video surveillance data streams, IoT sensor data streams, information system log data streams, and access control data streams. The aforementioned safety-related factual fragments are matched and associated with a pre-built campus factual knowledge base to construct a campus factual network diagram that reflects the interaction logic of people, things, and events within the campus. Based on the campus event network diagram, real-time perceived abnormal event fragments are injected as initial disturbances to drive the simulation and deduction model, which combines physical laws, to conduct event propagation and deduction in the virtual space represented by the campus event network diagram. Based on the campus event network diagram, the same initial disturbance is injected to drive the constraint deduction model combined with logical rules to perform condition constraint propagation deduction in the logical relationship represented by the campus event network diagram. By integrating the physical propagation path output by the simulation model with the logical constraint state output by the constraint model, multiple rounds of parallel simulations are performed to generate a set of simulation scenario snapshots describing the campus safety status at different future points in time. The state analysis and scenario convergence processing of the simulated scenario snapshot set are performed. Key scenarios of concern are selected based on preset thresholds, and representative future security scenarios are generated through cluster analysis. Then, the key event fragment sequences that led to the occurrence of each representative future security scenario are traced back in reverse. Based on the sequence of key event fragments and the future security scenario, a set of campus security early warning and response instructions with specific execution objects, execution actions, execution locations and execution times is generated.

[0007] According to a second aspect of this application, a campus security situation assessment and early warning system based on multi-source data fusion is provided. The multi-source data fusion campus security situation assessment and early warning system includes a machine-readable storage medium and a processor. The machine-readable storage medium stores machine-executable instructions. When the processor executes the machine-executable instructions, the multi-source data fusion campus security situation assessment and early warning system implements the aforementioned multi-source data fusion campus security situation assessment and early warning method.

[0008] According to a third aspect of this application, a computer-readable storage medium is provided, wherein computer-executable instructions are stored therein, and when the computer-executable instructions are executed, the aforementioned method for campus security situation assessment and early warning based on multi-source data fusion is implemented.

[0009] Based on any of the above aspects, the technical effect of this application is as follows: By collecting multi-source data streams from campus, including video surveillance, IoT sensor data, information system logs, and access control data, and analyzing discrete security-related event fragments in real time, this system constructs a campus event network diagram by matching and associating these fragments with a pre-built campus event knowledge base. This diagram presents the interaction logic of people, things, and events on campus. Based on this network diagram, it drives both a simulation model incorporating physical laws and a constraint model incorporating logical rules to perform event propagation and condition constraint propagation. The system then merges the output results for multiple rounds of parallel simulations. This allows for a comprehensive and dynamic simulation of the development process of campus security events from both physical and logical perspectives. It generates snapshots of scenarios describing the campus security status at different future points in time. By processing these snapshots, representative future security scenarios are generated, and key event fragment sequences are traced back to pinpoint the source of potential security threats. Finally, based on the key event fragment sequences and future security scenarios, a set of campus security early warning and response instructions is generated. This enables real-time and accurate assessment of the campus security situation and timely and effective early warning, significantly improving the efficiency and level of campus security management. Attached Figure Description

[0010] Figure 1 A flowchart illustrating the campus security situation assessment and early warning method based on multi-source data fusion provided in this application embodiment is shown. Figure 2 The diagram shows the component structure of the campus security situation assessment and early warning system based on multi-source data fusion provided in this application embodiment. Detailed Implementation

[0011] Figure 1 This paper illustrates a flowchart of a campus security situation assessment and early warning method and system based on multi-source data fusion provided in an embodiment of this application. The detailed steps include: Step S110: Collect multi-source data streams within the campus, and parse discrete security-related data fragments from the multi-source data streams in real time. The multi-source data streams include video surveillance data streams, IoT sensor data streams, information system log data streams, and access control data streams.

[0012] In this embodiment, a "Yuanhang Campus" system with a comprehensive security deployment is used as the application scenario. The first step is to collect and structure the heterogeneous data from multiple sources. Specifically, a video streaming server connects to network cameras deployed throughout the campus to acquire continuous video surveillance data streams. Simultaneously, an IoT gateway aggregates IoT sensor data streams reported by sensors distributed throughout various buildings, such as temperature sensors, smoke detectors, water immersion sensors, and door / window magnetic sensors. Furthermore, a system log collection interface is used to obtain information system log data streams from the campus's identity authentication system, financial system, and academic affairs system. Finally, the access control controller's communication interface collects real-time card swipe records and access status at each building's access points, forming an access control data stream.

[0013] Step S111: Perform frame-by-frame behavior analysis on the video surveillance data stream to identify the target's motion trajectory, stationary behavior, interactive behavior, and abnormal action patterns in the video frame, and combine the target's identity, behavior category, occurrence time, camera position coordinates, and behavior feature parameters into video event segments.

[0014] Specifically, for video surveillance data streams, the behavior analysis model deployed on the GPU server is first invoked for processing. This model takes a sequence of video frames as input and first identifies targets such as people and vehicles in the frame using a target detection algorithm, assigning a temporary target tracking identifier to each target, such as "P_12345". Then, a multi-target tracking algorithm (such as Sort or DeepSort) is used to associate the same target in consecutive frames, forming its motion trajectory in the pixel coordinate system. Analyzing this trajectory, if the coordinate change of the trajectory in a certain area (such as the laboratory entrance) is less than a preset dwell radius threshold, and the duration exceeds a dwell duration threshold, it is identified as a "dwelling behavior". If two trajectories are highly similar in space and time, they are identified as "interactive behavior". Simultaneously, the model analyzes the target's keypoint posture sequence; if postures such as falling or running deviate significantly from typical campus behavior patterns, they are marked as "abnormal action patterns". For each identified behavior, it is encapsulated into a video event segment. For example, the data structure of a video event segment can be represented as {target identifier: "P_12345", behavior category: "abnormal stay", occurrence time: "2024-03-15 14:23:05", camera location coordinates: "latitude and longitude pair (X_cam, Y_cam)", behavior feature parameters: "stay duration T_dwell=300 seconds, coordinates of the center point of the stay area (X_center, Y_center)"}.

[0015] Step S112: Perform threshold and mode judgment on the IoT sensing data stream, identify abnormal states such as sensor reading exceeding the safety threshold, sensor reading sudden change, and sensor data interruption, and combine the sensor device identifier, abnormal type, abnormal reading, abnormal start time, abnormal end time, and sensor physical location into an IoT event segment.

[0016] Specifically, for IoT sensor data streams, a sliding window and rule engine are used for processing. Each sensor data point contains a device identifier, timestamp, and reading. For example, a smoke sensor data point is {Device ID: "S_2101", Timestamp: "2024-03-15 14:25:10", Reading: "0.05%obscuration / m"}. A dynamic baseline is maintained for each sensor. When a new reading is received, it is compared with a preset static safety threshold (such as the smoke concentration threshold TH_smoke). If the reading exceeds TH_smoke, it is determined to be an "exceeded safety threshold" anomaly. Simultaneously, the current reading is compared with the average of historical readings over the previous W time windows. If the rate of change exceeds the abrupt change detection threshold, it is determined to be an "abrupt reading" anomaly. Furthermore, if no data is received from a sensor for more than the expected time interval, it is determined to be a "data interruption" anomaly. Once an anomaly is detected, an IoT event fragment is generated, such as {Device ID: "S_2101", Anomaly Type: "Reading Exceeds Limit", Anomaly Reading: "0.05", Anomaly Start Time: "2024-03-15 14:25:10", Anomaly End Time: "null" (indicating ongoing), Sensor Physical Location: "Room 201, Building A, Dormitory"}.

[0017] Step S113: Perform clustering and sequence analysis on the information system log data stream to identify abnormal login behavior, abnormal data access behavior, abnormal process call behavior, and abnormal network connection behavior, and combine user identifier, source address, destination address, operation type, operation timestamp, and risk level into information event fragments.

[0018] Specifically, for information system log data streams, a time-series-based clustering algorithm and a Markov chain-based sequence analysis model are used for processing. First, raw logs from different information systems are collected, such as login logs from the identity authentication system {User ID: "U_teacher01", Source Address: "IP_10.0.0.5", Operation Type: "Login Failed", Operation Timestamp: "2024-03-15 14:26:30"}. The clustering algorithm groups a large number of failed login logs originating from the same source address and targeting multiple different user IDs within a short period into a single category, identifying them as "abnormal login behavior". The sequence analysis model compares the current user's operation sequence (e.g., "access the academic affairs system - query grades - export database") with historical normal behavior sequence patterns. If the transition probability of the current sequence is lower than the abnormal threshold, it is identified as "abnormal data access behavior". For network connection logs, "abnormal network connection behavior" is identified by analyzing whether the target address is a known malicious IP or an abnormal port. After identifying the anomaly, combine information fragments, such as {User ID: "U_teacher01", Source Address: "IP_10.0.0.5", Destination Address: "IP_202.120.2.3", Operation Type: "Abnormal External Connection", Operation Timestamp: "2024-03-15 14:27:00", Risk Level: "High Risk"}.

[0019] Step S114: Perform rule and frequency analysis on the access control data stream to identify illegal intrusion events, tailgating events, abnormal permission events, and high-frequency abnormal access events. Combine the access personnel identifier, access point location, access timestamp, access result, and abnormal flag into access control event fragments.

[0020] Specifically, a rule-based real-time analysis engine is used to process access control data streams. Each original access control record includes the user identifier (e.g., campus card number "C_2021001"), access point location (e.g., "Library Entrance A"), access timestamp, and access result (e.g., "Allowed" or "Denyed"). When consecutive "Denyed" records are received but the door sensor reports a physical signal that the door has been opened, combined with the video analysis results of that access point (e.g., someone enters in the video), an "illegal entry event" rule is triggered, generating an access control event segment marked as "illegal entry". By analyzing the time interval between two valid access records at the same access point within a short period, if the interval is less than the tailgating time threshold, the latter access is marked as a "tailgating event". For records where the access result is consistently "Denyed", their permissions are analyzed; if the cardholder does not have permissions for that access point, it is marked as an "abnormal permission event". The system counts the number of abnormal accesses by the same person at different access control points within a unit of time. If the number exceeds the high-frequency threshold, it is marked as a "high-frequency abnormal access event". An example of the generated access control event fragment is: {Access Person ID: "C_2021001", Access Control Point Location: "Library Entrance A", Access Timestamp: "2024-03-15 14:30:22", Access Result: "Rejected", Exception Flag: "Permission Abnormal"}.

[0021] Step S115: Define a unified data structure for video data segments, IoT data segments, information data segments, and access control data segments. This data structure includes subject elements, action elements, object elements, time elements, space elements, and attribute elements.

[0022] Specifically, for subsequent fusion and correlation analysis, a unified and generalized data structure is defined. This structure contains six core elements: subject element, used to identify the initiator of the action, such as personnel ID "P_12345" or device ID "S_2101"; action element, used to describe what happened, such as "login", "over-limit", "access"; object element, used to identify the recipient of the action, such as "server" or "laboratory door"; time element, recording the time or period of the event, such as "2024-03-15T14:23:05Z"; spatial element, describing the physical or logical location of the event, such as latitude and longitude coordinates or network IP address range; and attribute element, used to store all other key-value pair parameters related to the event that cannot be classified into the above five categories, such as "{read value: 0.05, unit: % / m}".

[0023] Step S116: Standardize the format of the parsed video logic segments, IoT logic segments, information logic segments, and access control logic segments according to the unified logic segment data structure to generate standard logic segments.

[0024] Specifically, the various heterogeneous event fragments generated in steps S111 to S114 are mapped and formatted according to the structure defined in step S115. For example, the "target identifier" in the video event fragment is mapped to the "subject element," the "behavior category" is mapped to the "action element," and the "camera position coordinates" are mapped to the "spatial element" after coordinate transformation. After the transformation, a standard video event fragment becomes {subject: "P_12345", action: "abnormal stay", object: "null", time: "2024-03-15T14:23:05Z", space: "POINT(X_cam, Y_cam)", attribute: "{stay duration: 300, center point: (X_center, Y_center)}"}. All original fragments are converted into standard event fragments with the same format as above.

[0025] Step S117: Perform semantic disambiguation and normalization on the standard semantic fragments, map the action element words that express the same semantics in different data sources to specific words in the standard action lexicon, and map synonymous location descriptions to standard location coordinates or regional codes.

[0026] Specifically, a predefined standard action lexicon and standard location encoding table are loaded. In the standard action lexicon, terms such as "login," "login," and "signin" are uniformly mapped to "user login." In the standard location encoding table, descriptions such as "Room A-201," "Room A-201," and "Dormitory A-201" are uniformly mapped to the area code "Dorm_A_R201." Then, each standard event fragment is traversed, and its "action element" and "spatial element" are replaced using table lookups. For example, a standard event fragment from an information system, whose original action is "Login," becomes "user login" after mapping; its original space is the IP address "10.0.0.5," which can be mapped to the area code "Net_ServerRoom" through the IP address-physical location mapping table. This step eliminates ambiguity in the semantic expression of multi-source data.

[0027] Step S118: Assign a globally unique logic fragment identifier to each standard logic fragment that has undergone semantic normalization, and output the standard logic fragment carrying the logic fragment identifier as a security-related logic fragment.

[0028] Specifically, a distributed unique ID generation algorithm (such as the snowflake algorithm) is used to generate a globally unique, trend-increasing integer ID for each standard event fragment processed in step S117, such as "EF_1234567890". This ID is added as a new field, "Fragment Identifier," to the standard event fragment's data structure. At this point, the data structure containing the unique ID and having undergone semantic normalization is the final usable "security-related event fragment." Subsequently, each security-related event fragment is published as a message to the message queue of the subsequent processing module.

[0029] Step S119: Establish a cache queue of security-related event fragments, store newly generated security-related event fragments in chronological order, set a cache time window, and remove historical security-related event fragments that exceed the time window.

[0030] Specifically, a timestamp-sorted circular buffer or priority queue is constructed in memory as a cache for security-related event fragments. Whenever a new security-related event fragment is generated in step S118, it is inserted at the end of the cache queue. Simultaneously, a fixed cache time window length is set, for example, T_cache = 30 minutes. A background daemon thread periodically checks the timestamp of the oldest event fragment at the head of the queue. If the difference between the current time and the fragment's timestamp is greater than T_cache, the fragment is removed from the queue and persisted to the historical database. This operation ensures that the cache queue always retains only the most recent active event fragments within the T_cache timeframe, for subsequent matching and association with the knowledge base and real-time network graph construction.

[0031] Step S120: Match and associate the safety-related factual fragments with the pre-built campus factual knowledge base to construct a campus factual network diagram that reflects the interaction logic of people, things and events on campus.

[0032] Step S121: Load the pre-built campus event knowledge base, which includes an entity database, an event database, and a relationship rule database. The entity database stores personnel entities, equipment entities, location entities, system entities and their attributes. The event database stores typical security event templates. The relationship rule database stores physical association rules, logical association rules and causal association rules between entities.

[0033] Specifically, a campus event knowledge base, pre-built offline, is loaded into the in-memory database. The entity database is a collection of nodes in a graph database. For example, the attributes of the personnel entity node "Entity_ZhangSan" include {Name: "Zhang San", Role: "Student", Department: "School of Information Science"}; the attributes of the device entity node "Entity_Cam_A01" include {Type: "Camera", Location: "Library Entrance", IP Address: "192.168.1.10"}. The event database is a collection of typical safety event templates, such as the "Laboratory Fire" template, which defines the possible entity types involved {personnel, smoke detectors, fire hydrants}, typical action sequences {smoke alarm, personnel evacuation}, and attribute characteristics {smoke concentration threshold}. The relational rule base stores various rules, such as physical association rules: "If two entities are located in the same spatial area, then there is a physical association between them of 'sharing a room'"; logical association rules: "If person A is the registered user of equipment B, then there is a logical association between A and B of 'having permission'"; and causal association rules: "If a 'smoke alarm' event occurs, it may trigger a 'fire sprinkler activation' event, with a confidence level of 0.8".

[0034] Step S122: Match the safety-related factual fragments with the entity database in the campus factual knowledge base, identify the entity identifiers corresponding to the subject elements and object elements in the safety-related factual fragments, and if there is no completely matching entity, create a new entity node and supplement the attributes of the new entity node.

[0035] Specifically, for each security-related event fragment from step S118, the values ​​of its subject and object elements (normalized strings) are extracted. For example, a fragment might have the following structure: {Subject: "C_2021001", Object: "Door_Lib"}. Then, a fuzzy matching search is performed in the entity database. First, an exact match is attempted with the entity identifier, such as checking if a node with the entity ID "Entity_C_2021001" exists. If found, the entity ID is recorded. If not found, a new entity node is created, with its ID generated according to a rule such as "Entity_" + subject element value, i.e., "Entity_C_2021001". The initial attributes of the new entity are then added based on the attribute elements in the event fragment, such as {First appearance time: the fragment's time element, Source: fragment ID}. The same matching or creation operation is performed for the object element "Door_Lib". The result of the matching is associating the event fragment with a specific entity node, for example, recording the source entity ID and target entity ID associated with the fragment.

[0036] Step S123: Match the safety-related event fragments with the event database in the campus event knowledge base, calculate the similarity between the safety-related event fragments and each typical safety event template in terms of action elements and attribute elements, and classify the safety-related event fragments with similarity exceeding the threshold into the corresponding event type.

[0037] Specifically, the detailed implementation of this step will be described in subsequent steps S1231 to S1238.

[0038] Step S124: Taking the safety-related event fragment as the core, based on its time and space elements, search for spatiotemporal association rules in the relational rule base of the campus event knowledge base, and establish spatiotemporal association edges between the safety-related event fragment and other safety-related event fragments with similar time and adjacent space.

[0039] Specifically, from the cache queue in step S119, retrieve all other event fragments (denoted as fragments B) whose time difference with the currently processed event fragment (denoted as fragment A) is less than the time window threshold T_temporal, and whose spatial distance is less than the distance threshold D_spatial. The time difference is obtained by calculating the absolute value of the difference between the time elements of fragment A and fragment B. The spatial distance is obtained by calculating the Euclidean distance between the spatial element coordinates of fragment A and fragment B. Spatiotemporal association rules are defined in the relation rule base, such as "if two fragments occur at similar times and are spatially adjacent, then establish a 'spatiotemporal association'". For each pair (A, B) that meets the spatiotemporal threshold conditions, in the campus event network graph to be constructed, add a directed or undirected "spatiotemporal association edge" between the node corresponding to fragment A and the node corresponding to fragment B.

[0040] Step S125: Assign time proximity and spatial proximity as weights to each spatiotemporal related edge. Time proximity is calculated based on the time difference between security-related factual segments, and spatial proximity is calculated based on the spatial distance between security-related factual segments.

[0041] Specifically, for each spatiotemporal connection edge established in step S124, its weight is calculated. The temporal proximity weight W_temporal is defined as the normalized value of the reciprocal of the time difference, i.e., W_temporal = 1 / (1 + |T_A - T_B|), such that the smaller the time difference, the larger the weight. The spatial proximity weight W_spatial is defined as the normalized value of the reciprocal of the spatial distance, i.e., W_spatial = 1 / (1 + Dist(S_A, S_B)). The combined spatiotemporal weight W_st of the edge can be the product of W_temporal and W_spatial, or their weighted sum, depending on the specific rule definition. For example, W_st can be set to α. W_temporal+β W_spatial, where α and β are preset harmonic coefficients.

[0042] Step S126: Taking the safety-related event fragment as the core, based on its subject element, action element, and object element, search for logical causal rules in the relational rule base of the campus event knowledge base, and establish causal relationship edges between the safety-related event fragment and other safety-related event fragments that may cause its occurrence or may cause it.

[0043] Specifically, taking the action of the current event segment A as the core, the system searches the relational rule base for all rules whose conclusion actions partially match or contain the action of segment A. These rules describe the possible causes that lead to segment A. For example, the rule base might contain a rule: "If 'multiple access control verification failures' (cause) occurs, then 'illegal intrusion' (effect) may follow immediately." If the action of segment A is "illegal intrusion," then according to this rule, a causal relationship edge needs to be established between segment A and other event segments that occurred within a certain period of time with the action "multiple access control verification failures," pointing from cause to effect. Conversely, rules whose premise actions partially match the action of segment A are also searched to establish the direction of the edge between segment A and future segments that may be triggered by it. The direction of the edge reflects the direction of the causal relationship.

[0044] Step S127: Assign a causal confidence score as a weight to each causal relationship edge. The causal confidence score is calculated based on the frequency of the corresponding causal relationship in historical data and the confidence factor of the rule in the rule base.

[0045] Specifically, for each causal relationship edge established according to rule R, its weight W_causal is set as a comprehensive confidence level. This comprehensive confidence level consists of two parts: the static confidence level Conf_R of rule R itself (stored in the rule base, e.g., 0.8), and the dynamic confidence level Conf_hist calculated from historical statistical data. Conf_hist is calculated as follows: in historical data, after all events satisfying the preconditions of rule R have occurred, the number of times the conclusion event of rule R has occurred within a specified time window is counted, divided by the total number of times the precondition events have occurred. The final W_causal = γ Conf_R+δ Conf_hist, where γ and δ are weighting coefficients, and γ+δ=1. For example, if Conf_R=0.8, Conf_hist=0.6, γ=δ=0.5, then W_causal=0.7.

[0046] Step S128: Integrate all safety-related factual fragments as nodes, and integrate all spatiotemporal and causal related edges as edges to construct a weighted directed graph structure, which is the initial campus factual network graph.

[0047] Specifically, all security-related event fragments processed in steps S122 to S127 within the current time window are abstracted as nodes in the graph. The node's attributes include all six-tuple information of that event fragment and its globally unique identifier. All spatiotemporal and causal relationships established in steps S124 to S127 are abstracted as directed edges connecting two nodes in the graph (spatiotemporal relationships can also be considered undirected edges, but are usually assigned a direction or considered bidirectional edges for deduction purposes). Each edge carries its weight (W_st or W_causal) and type label ("spatiotemporal" or "causal"). Thus, a weighted directed graph with event fragments as nodes, relationships as edges, and rich attributes for both nodes and edges is constructed in the memory graph database—the initial campus event network graph.

[0048] Step S129: Eliminate redundant edges in the initial campus event network graph, persist the processed weighted directed graph structure, and establish a dynamic update interface for event fragments related to real-time security.

[0049] Specifically, after the graph is constructed, a redundant edge elimination algorithm is run. For example, for multiple edges of the same type connecting the same pair of nodes (such as "spatiotemporal association edges" established between the same pair of nodes due to multiple spatiotemporal proximity), only the edge with the highest weight is retained, or the average weight of these edges is calculated and merged into a new edge. At the same time, a weight threshold W_prune is set, and all weak association edges with weights lower than W_prune are deleted to simplify the graph structure and remove noise. The simplified campus event network graph is persistently stored in the graph database. Meanwhile, a message queue-based listening interface is established. When a new security-related event fragment is generated in the cache queue of step S119, the listening interface is triggered, and steps S122 to S129 are re-executed, dynamically inserting the new fragment as a new node into the stored campus event network graph, while updating the association edges with the old nodes, thereby realizing real-time dynamic updates of the network graph.

[0050] Step S1231: Read a typical safety event template from the event library of the campus affairs knowledge base. The typical safety event template defines the standard action element value and standard attribute element value range for the corresponding event type.

[0051] Specifically, in step S123, during event matching, the first template, denoted as template T, is retrieved from the event database. For example, template T is the "laboratory fire" event, with its defined standard action elements taking the values ​​{"smoke alarm", "temperature exceeds limit", "fire alarm button pressed"}, and its standard attribute elements taking the values ​​{smoke concentration > TH_smoke, temperature > TH_temp}. The template may also contain the weights of these elements in the matching calculation, for example, the action element weight W_act = 0.6, and the attribute element weight W_attr = 0.4.

[0052] Step S1232: Extract the actual values ​​of the action elements of the safety-related event fragments to be matched, and perform semantic similarity calculation with the standard action element values ​​of the typical safety event template to obtain the action element similarity score.

[0053] Specifically, from the current safety-related event fragment F to be matched, its action element value is extracted and denoted as Action_F. For example, Action_F = "smoke detector alarm". Using a pre-trained word vector model (such as Word2Vec or BERT), each standard action word (such as "smoke detector alarm") in the template T is converted into a vector. Then, the cosine similarity between the Action_F vector and each standard action word vector is calculated. The maximum similarity among all standard action words with Action_F is taken as the action element similarity score Sim_act between fragment F and template T. For example, Sim_act = 0.95 is calculated.

[0054] Step S1233: Extract the actual values ​​of the attribute elements of the security-related event fragments to be matched, and calculate the matching degree with the standard attribute element value range of the typical security event template to obtain the attribute element matching degree score.

[0055] Specifically, the attribute element set Attr_F is extracted from the logical fragment F. For example, Attr_F contains key-value pairs {"smoke concentration": "0.08", "unit": "%obscuration / m"}. For the standard attribute element value range defined in template T, the value of the corresponding key in Attr_F is checked one by one to see if it falls within that range. For example, it is checked whether 0.08 is greater than TH_smoke (assuming TH_smoke = 0.06). Since 0.08 > 0.06, this attribute matches successfully. The proportion of successfully matched attributes out of the total number of attributes is counted, or a weighted average match degree is calculated as the final attribute element match degree score Sim_attr. For example, Sim_attr = 1.0 (all matches).

[0056] Step S1234: Based on the predefined weights of the event template, the similarity score of the action element and the matching score of the attribute element are weighted and summed to calculate the comprehensive matching score between the security-related event fragment and the typical security event template.

[0057] Specifically, using the weights W_act and W_attr defined in template T, the comprehensive matching score Score=W_act is calculated. Sim_act+W_attr Sim_attr. Substituting the example value above, Score = 0.6 0.95 + 0.4 1.0 = 0.57 + 0.4 = 0.97.

[0058] Step S1235: Traverse all typical security event templates in the event library, and repeatedly execute the steps from reading typical security event templates to calculating the comprehensive matching score to obtain a list of comprehensive matching scores between the security-related event fragment and all event templates.

[0059] Specifically, for the next template in the event database, repeat steps S1231 to S1234 above. Assume the event database also contains templates such as "equipment failure" and "network attack". After calculation, the score of fragment F with the "equipment failure" template is 0.2, and the score with the "network attack" template is 0.1. Finally, a list is obtained: [(laboratory fire, 0.97), (equipment failure, 0.2), (network attack, 0.1)].

[0060] Step S1236: Find the highest score from the comprehensive matching score list. If the highest score exceeds the preset classification similarity threshold, classify the security-related logical fragment into the event type corresponding to the highest score.

[0061] Specifically, the classification similarity threshold is set to TH_classify=0.7. The highest score of 0.97 is found in the score list, corresponding to the event type "laboratory fire". Since 0.97>0.7, the safety-related event fragment F is classified under the event type "laboratory fire".

[0062] Step S1237: If the highest score does not exceed the classification similarity threshold, a new event type is created for the security-related logical fragment, and the security-related logical fragment is stored in the event library as the initial template of the new event type. At the same time, the security-related logical fragment is classified under the new event type.

[0063] Specifically, if the highest calculated score is assumed to be only 0.6, below the threshold of 0.7, then the existing event template library is considered inadequate to describe the segment. In this case, a new event type is created in the event library, temporarily named after the action element of the segment, such as "abnormal fluctuation of smoke detector". This safety-related event segment F is stored in the event library as the first instance template of this new event type, and the standard actions and attribute values ​​of the template will be extracted from F. Simultaneously, F is categorized under this newly created "abnormal fluctuation of smoke detector" event type.

[0064] Step S1238: Tag the security-related event fragments classified under the event type with event type labels, record the matching score of each security-related event fragment and its event type, and repeat the steps from reading the first typical security event template to recording the matching score for all newly generated security-related event fragments to complete the real-time matching and classification of security-related event fragments with the event library.

[0065] Specifically, in the data structure of safety-related event fragment F, a new field "Event Type Label" is added, and its value is set to "Laboratory Fire". Simultaneously, a new field "Match Confidence" is added, and its value is set to 0.97. After processing fragment F, the next new fragment is retrieved from the message queue of step S119, and the entire process from steps S1231 to S1238 is repeated, thereby achieving continuous matching and classification of the real-time data stream.

[0066] Step S130: Based on the campus event network diagram, inject real-time perceived abnormal event fragments as initial disturbances to drive the simulation and deduction model combined with physical laws to perform event propagation and deduction in the virtual space represented by the campus event network diagram.

[0067] Step S131: From the real-time perceived security-related event segments, filter out the abnormal event segments that are marked as abnormal. The abnormal event segments include abnormal actions in video event segments, device failures in IoT event segments, network attacks in information event segments, and illegal intrusions in access control event segments.

[0068] Specifically, continuously monitor the security-related event fragment stream output in step S118. For each arriving fragment, check whether its attribute element contains an "abnormal flag" field, or whether its event type label belongs to a predefined list of abnormal events (e.g., "illegal intrusion," "smoke alarm," etc.). If a fragment meets either of the above conditions, it is filtered out and placed in a high-priority "abnormal event fragment queue" as a potential initial disturbance.

[0069] Step S132: Select one or more of the abnormal event fragments as initial perturbation fragments, map the initial perturbation fragments to the corresponding nodes in the campus event network graph, activate the nodes, and mark their states as occurred.

[0070] Specifically, based on current analysis needs or predefined strategies, one or more segments are selected from the abnormal event segment queue as the starting point for this simulation. For example, a "illegal entry into the library" segment and a "smoke alarm" segment occurring at the same time in the laboratory are selected. Using the globally unique identifier carried by each segment, the corresponding node is found in the campus event network graph constructed in step S128, and the status attribute of the above node is changed from "to be observed" or "normal" to "occurred", and the current simulation round is counted as round 0.

[0071] Step S133: Based on the event type of the initial disturbance segment, match the corresponding event physical propagation model from the physical law library, which includes crowd flow model, information diffusion model, fault transmission model, and fire spread model.

[0072] Specifically, for the "unauthorized access control entry" segment, the event type might be categorized as an "intrusion event," and a "personnel evacuation model" would be matched from the physics database. This personnel evacuation model is based on a social force model to describe the movement and crowding behavior of people in a panic state. For the "smoke alarm" segment, a "fire spread model" would be matched. This personnel evacuation model is based on a simplification of computational fluid dynamics and is used to simulate the spread of fire, smoke, and heat in a building space. The physics database stores the algorithm implementations or API calls for these models.

[0073] Step S134: Input the spatial elements of the nodes in the campus event network diagram, the campus geographic information data, and the current environmental parameters into the matching event physics propagation model, and initialize the parameters of the event physics propagation model.

[0074] Specifically, spatial elements, such as their three-dimensional coordinates (X_lib_door, Y_lib_door, Z_lib_door), of entity nodes (e.g., the "library entrance" location entity) associated with the activated node (e.g., the "illegal entry into the library entrance" node) are extracted from the campus event network graph. Internal structural data of the library, including room layout, corridors, staircases, and door / window locations, is loaded from the campus Geographic Information System (GIS) database and represented as a raster map or navigation mesh. Simultaneously, current environmental parameters, such as temperature T_env, humidity H_env, and wind speed W_env, are obtained. This data is used as initial parameters and input into the "personnel evacuation model" to initialize the model, setting the simulation area, obstacles, and initial personnel distribution (which can be obtained through other camera data).

[0075] Step S135: Based on the event physics propagation model, calculate the influence intensity of the active node on its neighboring nodes in physical space. The influence intensity is determined by the physical distance attenuation factor, the medium blocking factor, and the energy attenuation factor.

[0076] Specifically, taking the "fire spread model" as an example. The activated node corresponds to the fire source location P0. For other nodes spatially adjacent to P0 in the campus network diagram (e.g., node P1 representing a nearby room), the influence intensity I of the fire source is calculated. The influence intensity I is a comprehensive value. First, the physical distance attenuation factor is calculated, i.e., 1 / (1+Dist(P0, P1)). The closer the distance, the greater the influence. Second, the medium barrier factor: GIS data is used to determine whether there is a wall between P0 and P1. If there is a wall, a barrier coefficient B_wall (between 0 and 1) is introduced based on the fire resistance rating of the wall material. For example, the B_wall of a firewall is very small, while the B_wall of ordinary glass is close to 1. The distance attenuation factor is multiplied by the barrier coefficient to obtain the propagation basis factor considering obstacles. Finally, the energy attenuation factor: considering the intensity of the fire source itself, such as the heat release rate HRR, and the energy loss during propagation, a coefficient E_decay is obtained that decays with time or distance. The final influence intensity I = (1 / (1+Dist)). B_wall E_decay.

[0077] Step S136: Based on the influence intensity and the weights of the edges in the campus event network graph, calculate the physical trigger probability of neighboring nodes being triggered at the physical level. The physical trigger probability is a function of the influence intensity and the weights of the spatiotemporal related edges.

[0078] Specifically, for a neighboring node P1, the probability P_physical of being physically triggered is determined by two parts: the physical influence intensity I calculated in step S135, and the weight W_st (if it exists) of the "spatiotemporal association edge" from the fire source node (or activated node) to node P1 in the campus event network graph. If there is no direct edge between the two nodes, W_st takes a minimum value. The physical triggering probability P_physical = f(I, W_st), where f is a function, for example, it can be defined as P_physical = min(1, I...). (1+λ) W_st), where λ is an adjustment coefficient used to amplify the effect of spatiotemporal correlation on physical propagation. For example, if I=0.6, W_st=0.8, and λ=0.5, then P_physical=min(1, 0.6). (1+0.5) 0.8))=min(1,0.6) 1.4) = 0.84.

[0079] Step S137: Using Monte Carlo simulation or deterministic threshold judgment, determine whether neighboring nodes are activated at the physical level based on the physical trigger probability, and add the newly activated nodes to the set of nodes that have occurred.

[0080] Specifically, the Monte Carlo method can be used: generate a uniformly distributed random number R between 0 and 1 for each neighboring node P1 to be evaluated. If R is less than P_physical, then node P1 is determined to be physically activated, its state is marked as "occurred", and it is added to the set of newly activated nodes in this round. If a deterministic threshold is used, an activation threshold TH_activate is set, for example, 0.7. A node is only considered activated when P_physical > 0.7.

[0081] Step S138: Use the newly activated node as the source point for the new round of deduction, and repeat the steps from matching the physical propagation model of the event to determining whether the node is activated, to perform iterative deduction of physical propagation.

[0082] Specifically, the set of newly activated nodes in step S137 is used as the source node for the next round (i.e., round 2). For each new node in the set, the corresponding physical propagation model is re-matched according to its event type (this may be the same as the previous round or different; for example, a person arriving in a room may cause "equipment overload" in that room). Then, steps S134 to S137 are repeated to calculate their impact on their respective neighboring nodes. This process is iterated continuously.

[0083] Step S139: Record the newly activated nodes and the iteration number of each iteration in each round of deduction to form an event propagation path based on physical laws. The event propagation path is a sequence of nodes arranged in chronological order.

[0084] Specifically, in each iteration, when a node is activated, in addition to marking its state, it is also recorded which round of the deduction was activated, and which (or which) previous round's node caused its activation (i.e., its parent node). All activated nodes, ordered according to their activation rounds, constitute one or more paths that spread in physical space from the initial perturbation. For example, path 1: Node A (round 0) -> Node B (round 1) -> Node C (round 2). This path is stored as a record in the graph data structure.

[0085] Step S1310: When the iterative simulation reaches the preset maximum number of rounds, or when no new node is activated in the new round of simulation, terminate the physical propagation simulation and output the final event propagation path and the physical trigger probability and round information of each node being activated.

[0086] Specifically, the maximum number of simulation rounds is preset to N_max, for example, 10 rounds. If, after the 5th simulation round, the physical trigger probabilities of all neighboring nodes calculated in step S137 are lower than the activation threshold, resulting in no new nodes being activated, the simulation reaches a stable state and terminates early. If nodes are continuously activated until the 10th round, the simulation is forcibly terminated after the 10th round. Finally, the output of the physics simulation model is a set containing a list of all activated nodes, each node accompanied by its activation round, the calculated physical trigger probability, and multiple physical propagation paths connecting these nodes through propagation relationships.

[0087] Step S140: Based on the campus event network diagram, inject the same initial disturbance to drive the constraint deduction model combined with logical rules to perform condition constraint propagation deduction in the logical relationship represented by the campus event network diagram.

[0088] Step S141: From the real-time perceived security-related event segments, filter out the abnormal event segments that are marked as abnormal. The abnormal event segments include abnormal actions in video event segments, device failures in IoT event segments, network attacks in information event segments, and unauthorized intrusions in access control event segments.

[0089] Specifically, this step is exactly the same as step S131, ensuring that the physical deduction and logical deduction are based on the same initial set of abnormal events. Initial perturbations are also selected from the "abnormal event fragment queue".

[0090] Step S142: Select one or more of the abnormal event fragments as initial constraint perturbation fragments, map the initial constraint perturbation fragments to the corresponding nodes in the campus event network graph, and mark the state of the nodes as condition satisfied or condition violated.

[0091] Specifically, the same initial disturbance segments as in step S132 are selected, such as the "illegal access control" segment and the "smoke alarm" segment. The corresponding nodes are then located in the campus event network diagram. At this point, the way the node state is marked differs from the physical deduction. Instead of simply marking it as "occurred," it is marked as a certain logical state based on its event type and the definition of the logical rule base. For example, the "smoke alarm" node is marked as "fire alarm conditions met." The "illegal access control" node is marked as "security violation conditions violated."

[0092] Step S143: Load logical constraint rules related to the nodes of the campus event network graph from the logical rule base. The logical rule base includes state dependency rules, resource contention rules, temporal constraint rules, and permission constraint rules.

[0093] Specifically, the logical rule base is a predefined collection describing the logical order that the system should follow. For example, a state dependency rule: "If a fire occurs in a certain area (condition), then all access control systems in that area should be forcibly unlocked (conclusion)." A resource contention rule: "If the emergency generator has started (condition), then non-critical loads (such as the air conditioning system) should be shut down (conclusion)." A timing constraint rule: "After an 'illegal entry' event occurs, security personnel must arrive to handle the situation within T_response time; otherwise, it is considered a 'response timeout' violation." A permission constraint rule: "Only personnel with 'laboratory administrator' permissions are considered legitimate to enter the laboratory outside of working hours; otherwise, it is considered a 'permission violation.'" Load all rules that may be related to the node types in the current network graph.

[0094] Step S144: Traverse the campus network diagram and find all logical constraint rules that take the current state of the marked node as a prerequisite, forming a set of rules to be evaluated.

[0095] Specifically, using the set of nodes currently marked with logical states (initially the two nodes marked in step S142) as an index, the entire logical rule base is scanned. Rules whose preconditions contain the events or states represented by these nodes are identified. For example, for a node marked "fire alarm conditions met," rules whose preconditions include "fire occurred," such as "force unlock access control" and "cut off non-critical loads," are found. These rules are then placed into a queue of rules to be evaluated.

[0096] Step S145: For each rule in the set of rules to be evaluated, check whether all its preconditions are met. If all are met, trigger the rule and execute the conclusion action of the rule. The conclusion action may be to activate a new node, disable a node, or modify the node attributes.

[0097] Specifically, a rule, such as "forced unlock access control," is taken from the queue of rules to be evaluated. Its prerequisite is "fire has occurred." In the current network graph, the state of the "laboratory smoke alarm" node is "fire alarm conditions met," which is considered a specific manifestation of "fire has occurred." If this is the only prerequisite condition required by the rule, then all prerequisite conditions for the rule are met. Therefore, the rule is triggered. The rule's concluding action is "activate a new node," that is, activate a new node representing "forced unlock access control in the library" in the network graph (if the node already exists, update its state). Simultaneously, another rule, "disconnect non-critical loads," is executed, whose concluding action might be "modify node attributes," that is, modify the attribute of the node representing the "air conditioning system" to "disconnected."

[0098] Step S146: If the conclusion action of the rule is to activate a new node, then calculate the logical activation confidence of the new node at the logical level. The logical activation confidence is calculated based on the confidence of the rule itself and the degree to which the preconditions are satisfied. If the conclusion action of the rule is to prohibit a node, then mark the state of the node as logically prohibited and reduce the possibility of it being activated by other rules.

[0099] Specifically, for the "force unlock access control" rule, the logical activation confidence C_logical of the newly activated node is set to the rule's own confidence Conf_rule (e.g., 0.95) multiplied by the product of the degree to which all preconditions are satisfied (if the preconditions exist in fuzzy logic form). Here, the preconditions are fully satisfied, set to 1.0, then C_logical = 0.95. For the "cut off non-critical load" rule, the conclusion is to modify the attribute of the "air conditioning system" node, marking its state as "logically prohibited". A node marked as "logically prohibited" will have its activation probability multiplied by a penalty factor (e.g., 0.1) in subsequent logical deductions, even if other rules attempt to activate it, making it extremely difficult to activate.

[0100] Step S147: Treat the newly added state nodes, logically prohibited nodes, and modified attributes affected by the rules triggered in this round as new constraint changes, and update the state of the corresponding nodes in the campus affairs network diagram.

[0101] Specifically, the newly activated "Library Access Control Forced Unlock" node in step S146 is added to the network graph, and its logical state is marked as "activated". The state attribute of the "Air Conditioning System" node is updated to "Logically Prohibited". The above nodes and their state changes constitute the result of this round of logical deduction.

[0102] Step S148: Using the newly added state node as a new condition, repeat the steps from finding the set of rules to be evaluated to updating the node state to perform iterative propagation and deduction of logical constraints.

[0103] Specifically, the newly added state node "Library Access Control Forced Unlock" in step S147 is considered a new condition. Step S144 is executed again to find rules that presuppose "Access Control is unlocked". For example, there might be a rule: "If the access control is forcibly unlocked (condition), then trigger the area broadcast system to play an evacuation notice (conclusion)". This rule is then added to the set to be evaluated and triggered when the condition is met, activating the "Play Evacuation Notice" node. This process continues to propagate like a chain.

[0104] Step S149: Record the nodes where the state changes, the type of change, and the rules that trigger the change in each round of logical deduction, forming a logical constraint propagation chain, which describes the derivation process of logical state changes.

[0105] Specifically, each time a rule is triggered, a reasoning record is recorded: Rule R, based on the set of premise nodes P, derives conclusion node C with a confidence level of C_logical. All these reasoning records are connected according to the rounds to form one or more logical reasoning trees originating from the initial perturbation node, i.e., logical constraint propagation chains. This clearly demonstrates how the logical conclusion is derived step by step.

[0106] Step S1410: When the logical deduction reaches a stable state, the logical constraint propagation deduction is terminated, and the final logical state of each node and the logical constraint propagation chain are output. The stable state is used to reflect when no new rules are triggered or the node state no longer changes.

[0107] Specifically, the logic deduction terminates when no new rules can be triggered, or when the states of all nodes remain unchanged for two consecutive rounds of deduction. For example, after deriving "play evacuation notice," there may be no other rules presupposing that node. At this point, the logic deduction reaches a stable state and terminates. The output is a network graph where all nodes are labeled with their final logical state (e.g., "activated," "logically prohibited," "pending"), and one or more logical constraint propagation chains connecting these nodes, each labeled with a rule.

[0108] Step S150: Integrate the physical propagation path output by the simulation model with the logical constraint state output by the constraint model, perform multiple rounds of parallel simulation, and generate a set of simulation scenario snapshots describing the campus security status at different future points in time.

[0109] Step S151: In the simulation initialization phase, set the total number of parallel simulation rounds and the time step of each simulation round, and initialize an empty simulation scene snapshot set.

[0110] Specifically, the total number of parallel simulation rounds is set to K, for example, K=5 rounds. Each round of parallel simulation corresponds to a fixed time step Delta_T in the real world, for example, Delta_T=1 minute. This means that each round of simulation simulates the evolution of the campus security state in the next minute. At the same time, an empty list SceneSnapshotList is created in memory to store snapshots of the simulation scenes generated later.

[0111] Step S152: For the first round of simulation, merge the list of nodes activated in the first round of simulation in the physical propagation path output by the simulation model with the list of nodes whose states changed in the first round of simulation in the logical constraint state output by the constraint simulation model.

[0112] Specifically, from the physical propagation path obtained in step S1310, all nodes activated in the first round of physical deduction (i.e., within time step 1) are extracted to form the list Phy_Activated_1. From the logical constraint propagation chain obtained in step S1410, all nodes whose state changed to "activated" in the first round of logical deduction are extracted to form the list Log_Activated_1. Now, these two lists need to be merged to determine which events are considered to have "actually occurred" after the first round of parallel deduction.

[0113] Step S153: During the fusion process, check the same node in the two node lists. If the node is activated in the physical propagation path and is allowed to be activated in the logical constraint state, then the node is identified as a security event that occurred after the first round of simulation.

[0114] Specifically, the intersection of Phy_Activated_1 and Log_Activated_1 is taken. For example, if the node "Room101_Smoke Detector Activated" appears in both lists, it means that the fire has physically spread to Room 101, and logically there is no rule to prevent this event from occurring. Therefore, this node is identified as the actual safety event that occurred after the first round of simulation.

[0115] Step S154: If a node is only activated in the physical propagation path but is marked as logically prohibited in the logical constraint state, then the node is suppressed and not counted as a security event.

[0116] Specifically, take the difference between Phy_Activated_1 and Log_Activated_1. For example, the node "Air Conditioning System_Overload" is activated in the physical propagation path (due to a circuit failure caused by a fire), but in the logical constraint state, the "Air Conditioning System" node has been marked as "Logically Prohibited" (cut off due to a fire according to step S146). Therefore, the physical "overload" event will not actually occur because it is suppressed by the logical rule. This node is not included in the final event.

[0117] Step S155: If a node is activated in a logically constrained state but is not within the coverage area of ​​the physical propagation path, it is necessary to evaluate the node's spatial attributes and the residual effects of the physical propagation model to determine whether it has occurred with a certain probability.

[0118] Specifically, take the difference between Log_Activated_1 and Phy_Activated_1. For example, the node "Library Access Control Forced Unlock" is logically activated, but it is not a physically propagated event. Its probability of occurrence does not depend on physical propagation, but is determined by the confidence level of the logical rule, i.e., C_logical. However, the residual effects of physical propagation can also be considered. For example, if a fire is physically close to the access control, it may burn the access control circuit, which may in turn prevent it from unlocking. Therefore, the final probability of occurrence P_final = C_logical (1-I_damage), where I_damage is the intensity of the destructive impact of physical propagation on the node. If I_damage is very large, even if it is logically activated, it cannot be physically realized.

[0119] Step S156: Determine the set of security event nodes that will be triggered after the first round of simulation, and the estimated probability of occurrence of each event node.

[0120] Specifically, by combining the results of steps S153, S154, and S155, a final set of security event nodes, Final_Events_1, is obtained. For each node E in the set, its occurrence probability P_E is determined based on its source. For nodes from the intersection, P_E is equal to its physical trigger probability P_physical (or some combination with the logical confidence level, such as taking the average). For nodes from the difference set (logic-specific), P_E is equal to the probability after correction for physical residual effects.

[0121] Step S157: Based on the set of triggered event nodes, update the state of the nodes in the campus event network graph and generate a snapshot of the campus security status after the first round of simulation. The snapshot of the campus security status includes the currently occurring events, event locations, event probabilities, and an assessment of the overall risk level of the campus.

[0122] Specifically, the state of the corresponding nodes in the campus event network graph is updated using the Final_Events_1 set. Then, the first snapshot, Snapshot_1, is generated. This snapshot is a data structure containing: a timestamp (initial time + Delta_T), a list of events that have occurred, Final_Events_1 (each event with ID, location, and probability), and the overall campus risk level, Risk_1, calculated based on these events. Risk_1 can be calculated by weighting the probabilities of all events that have occurred with their severity levels and then normalizing the result.

[0123] Step S158: Add the snapshot of the campus security status after the first round of simulation to the simulation scenario snapshot set; take the snapshot of the campus security status after the first round of simulation as the new initial state, feed the new initial state back to the simulation model and the constraint simulation model, and start the second round of simulation.

[0124] Specifically, Snapshot_1 is added to SceneSnapshotList. Then, Final_Events_1 contained in Snapshot_1 is used as a new round of known facts and fed back to the physical simulation model and the logical constraint model as initial conditions for their second round of calculations. This marks the start of the second round of parallel simulation.

[0125] Step S159: The simulation model continues to perform physical propagation based on the new set of already occurred event nodes, and outputs the second round of physical propagation path; the constraint model continues to perform logical constraint propagation based on the new node state, and outputs the second round of logical constraint state.

[0126] Specifically, the detailed implementation of this step will be described in subsequent steps S1591 to S1596.

[0127] Step S1510: Repeat the steps from merging the two lists to generating a state snapshot to complete the second round of simulation, generate a campus security state snapshot after the second round of simulation, and add it to the simulation scenario snapshot set until the preset total number of simulation rounds is reached. Finally, a set of simulation scenario snapshots arranged in chronological order is generated, and each snapshot describes the campus security state at the corresponding future time point.

[0128] Specifically, the two outputs from the second round are used as input again to execute steps S152 to S157, generating Snapshot_2 and adding it to the list. This process is repeated until the Kth round of deduction is completed, generating Snapshot_K. Finally, SceneSnapshotList contains snapshots of the campus security status at the 1st minute, 2nd minute...Kth minute after the current time, forming a set of scenarios describing future evolution trends.

[0129] For example, step S1591: Extract a list of all security event nodes marked as having occurred from the campus security status snapshot after the first round of simulation, as well as the detailed attributes of each event node.

[0130] Specifically, at the start of the second round of simulation, the Final_Events_1 list is read from Snapshot_1. This list contains, for example, the event node "Room101_Smoke Detector Activation" and its attributes, such as {Location: "Room101", Intensity: "Medium", Probability: 0.9}.

[0131] Step S1592: Convert the list of security event nodes and their detailed attributes into a physical state input format that can be recognized by the simulation model. The physical state input format includes parameters such as event type, location of occurrence, intensity of occurrence, and scope of influence.

[0132] Specifically, a structure called PhysicalInput is defined for communication with the physical simulation model. Each event in Final_Events_1 is mapped to a PhysicalInput. For example, the "Room101_Smoke Detector Activation" event is converted to PhysicalInput{Event Type: "Fire", Occurrence Location: "(X_101, Y_101)", Occurrence Intensity: mapped to heat release rate HRR_medium based on the "medium" attribute, Influence Range: initial radius R_init}.

[0133] Step S1593: Input the converted physical state input format, along with the updated environmental parameters, as new initial conditions into the simulation model.

[0134] Specifically, the PhysicalInput list generated in step S1592, along with the latest environmental parameters obtained from the weather station (such as wind direction changing to northerly), are input into the physical simulation model (such as the fire spread model) as the initial fire source and boundary conditions for the second round of model calculation.

[0135] Step S1594: The simulation model resets its internal state based on the new initial conditions, and recalculates the physical propagation impact with the currently occurring event nodes as the new propagation source, and conducts a new round of physical propagation simulation.

[0136] Specifically, the physical model clears the intermediate calculation results of the previous round, takes the position in PhysicalInput as the new fire source point, combines the new wind direction, and re-executes the algorithm in steps S135 to S139 to calculate which neighboring nodes will be affected and the probability of the impact from these new fire source points within the second round time step, thereby outputting the physical propagation path of the second round.

[0137] Step S1595: Simultaneously, the list of security event nodes that have occurred and their detailed attributes are converted into a logical state input format that can be recognized by the constraint inference model. The logical state input format includes event type, occurrence status, associated entity, and resource occupancy status.

[0138] Specifically, a structure `LogicInput` is defined for communication with the logical constraint model. Each event in `Final_Events_1` is converted into a `LogicInput`. For example, the event "Room101_Smoke Detector Activated" is converted into `LogicInput{Event Type: "Fire Alarm", Occurrence Status: "true", Associated Entity: "Room101", Resource Occupancy Status: "Occupying Firefighting Resources"}`.

[0139] Step S1596: Input the transformed logical state input format into the constraint inference model. Based on the new logical state input format, the constraint inference model resets its internal reasoning state and, with the current node state as the new condition, re-triggers the relevant rules to conduct a new round of logical constraint propagation inference.

[0140] Specifically, the LogicInput list is input into the logical constraint deduction model. The model clears the intermediate states derived from the previous round of reasoning (such as "library access control forced unlocking"), but retains the final state determined in Snapshot_1. Then, using these new inputs as the current known facts, the rule matching and triggering process of steps S144 to S149 is re-executed to deduce what new logical state changes will occur in the second round based on the new fire situation, thereby outputting the logical constraint state of the second round.

[0141] Step S1597: When the simulation model and the constraint model are performing the second round of simulation calculations, the local update of the campus event network diagram is started simultaneously.

[0142] Specifically, a concurrent thread or process is started to dynamically adjust the campus event network graph based on the results of the first round of inference, Snapshot_1. For example, if Snapshot_1 determines that a fire has occurred in "Room101", then the "safety status" attribute of the node representing "Room101" in the network graph is updated to "dangerous". At the same time, if it is found that the fire has caused a change in the dependency relationship of a nearby node (such as "server"), a new temporary causal edge may be added to the network graph, such as the causal edge of "Room101 fire" -> "server crash", and its confidence level is set according to expert experience.

[0143] Step S1598: Based on the results of the first round of deduction, update the state attributes of relevant nodes in the campus affairs network diagram, and dynamically add or prune the association edges between nodes based on new strong associations discovered in the deduction.

[0144] Specifically, this step is the specific operation of step S1597. After updating the node attributes, analyze the chronological order and correlation strength of events during the simulation process. If, in historical data or the current simulation, it is found that the "Room 101 fire" event is always followed by the "power room trip" event with a high probability, and the above correlation is not covered by the existing rule base, then a high-weight causal relationship edge can be dynamically added between these two nodes in the network graph. Conversely, if the weight of some edges is very low in multiple simulations, they are pruned.

[0145] Step S1599: Wait for the simulation model to complete the second round of physical propagation calculation and output the second round of physical propagation path; wait for the constraint model to complete the second round of logical constraint propagation calculation and output the second round of logical constraint state.

[0146] Specifically, the main fusion thread waits for the computation results of the physical deduction model and the logical deduction model. The computation of these two models may be parallel. Once both return their results, the two inputs required for the second round of deduction are obtained.

[0147] Step S15910: Send the updated campus event network diagram, the second round of physical propagation path, and the second round of logical constraint state into the fusion and decision module to generate a snapshot of the campus security status after the second round of simulation.

[0148] Specifically, the updated campus event network diagram in step S1598, and the second-round physical propagation path and second-round logical constraint state obtained in step S1599 are used as inputs to call the fusion logic in steps S152 to S157 again, thereby generating the second-round campus security status snapshot Snapshot_2.

[0149] Step S160: Perform state analysis and scene convergence processing on the set of simulated scene snapshots, filter out key focus scenes based on preset thresholds, generate representative future security scenes through cluster analysis, and then trace back the key event sequence that led to the occurrence of each representative future security scene.

[0150] Step S161: For each simulation scenario snapshot in the simulation scenario snapshot set, extract the list of security event nodes that have occurred, the probability of occurrence of each event node, and the overall risk level assessment value of the campus.

[0151] Specifically, iterate through SceneSnapshotList, and for each snapshot Snapshot_i, extract three core parts: the event list Events_i={E_i1, E_i2, ...}, the probability P_ij corresponding to each event E_ij, and the overall risk value Risk_i for that snapshot.

[0152] Step S162: Calculate the probability of occurrence of each scenario snapshot, which is approximately obtained by the joint probability of all event nodes that have occurred in the snapshot.

[0153] Specifically, to simplify the calculation, we assume that the occurrence of each event within a snapshot is independent. Therefore, the probability of a scene occurring, P_scene_i, can be approximated as the product of the probabilities of all events, i.e., P_scene_i = ΠP_ij. If we consider the dependencies between events, a more complex joint probability calculation is required, but here we use a product as an approximate estimate.

[0154] Step S163: Calculate the scene impact degree of each simulation scenario snapshot, where the scene impact degree is the weighted sum of the preset severity levels of all event nodes that have occurred in the snapshot; at the same time, obtain the overall campus risk level assessment value of the simulation scenario snapshot.

[0155] Specifically, each event type has a predefined severity level (e.g., 1-10). The formula for calculating the scene's impact level, Impact_i, is Impact_i = Σ(P_ij) Severity(E_ij)). This value is a weighted sum that considers both the severity of the event and its probability of occurrence. The Risk_i value is also read directly from the snapshot.

[0156] Step S164: Plot all the inferred scene snapshots on the probability influence two-dimensional plane with the probability of scene occurrence as the horizontal axis and the degree of scene influence as the vertical axis.

[0157] Specifically, a two-dimensional coordinate system is constructed, where the X-axis represents P_scene (ranging from 0 to 1) and the Y-axis represents Impact (ranging from 0 to 1, which may need to be normalized). For each snapshot in SceneSnapshotList, it is represented as a point on this plane based on its (P_scene_i, Impact_i) coordinates. In this way, all possible future scenes are distributed as points on this plane.

[0158] Step S165: On the two-dimensional plane of probability influence, based on the preset probability judgment threshold and influence degree judgment threshold, filter out the inferred scene snapshots whose scene occurrence probability is greater than the probability judgment threshold or whose scene influence degree is greater than the influence degree judgment threshold, as a preliminary candidate scene set.

[0159] Specifically, a probability threshold of TH_p is set, for example, 0.1 (probability of occurrence exceeds 10%); and an impact threshold of TH_impact is set, for example, 0.5 (impact exceeds 0.5). Two straight lines, X=TH_p and Y=TH_impact, are drawn on a two-dimensional plane. Snapshots of the inferred scenarios corresponding to all points located to the right of these two lines (X>TH_p) or above them (Y>TH_impact) are selected to form a "preliminary candidate scenario set" (CandidateSet). This ensures that scenarios with high probability or high impact are given priority.

[0160] Step S166: Perform cluster analysis on the preliminary candidate scenario set based on event node characteristics, occurrence probability and impact degree, and merge scenarios in the same cluster into the same representative future security scenario.

[0161] Specifically, for each scene in the CandidateSet, its event list Events_i is transformed into a feature vector. For example, one-hot encoding can be used to indicate whether a critical event occurs in the scene. The feature vector can also contain the scene's probability P_scene_i and its impact level Impact_i. Then, a clustering algorithm (such as K-means or DBSCAN) is used to cluster the above feature vectors. The clustering algorithm groups scenes with similar features into one class (cluster). For each cluster, all the scenes it contains are merged to generate a "representative future security scene" RepScene_k. The merging method can be to take the union of the event lists of all scenes in the cluster (or the frequently occurring events), and average the probability and impact level.

[0162] Step S167: Calculate the average probability of occurrence and the average impact of each representative future security scenario, and sort them according to the average impact.

[0163] Specifically, for each representative scenario RepScene_k, its average occurrence probability P_avg_k (i.e., the average of all scenarios P_scene within its cluster) and average impact severity Impact_avg_k (i.e., the average of all scenarios Impact within its cluster) are calculated. Then, all representative scenarios are sorted from high to low according to Impact_avg_k to obtain a priority list. The scenarios with the highest impact severity will be analyzed and dealt with first.

[0164] Step S168: For each representative future security scenario, starting from the snapshot of the scenario that constitutes the representative future security scenario, trace back the preceding event nodes that led to the state of the representative future security scenario along the reverse path of parallel deduction.

[0165] Specifically, taking the top-ranked representative scenario RepScene_1 as an example, find all the original inference snapshots that make up it (e.g., Snapshot_3, Snapshot_5). For each snapshot, such as Snapshot_3, it was generated at the end of the 3rd round of inference. Now, trace back along the reverse path of the parallel inference. The reverse path refers to seeing which events in Snapshot_2 were derived from the events in Snapshot_2 through physical or logical inference. This requires querying the physical propagation path recorded in step S139 and the logical constraint propagation chain recorded in step S149. By repeatedly tracing back the events of the previous round, we can eventually trace back to the initial perturbation node of round 0.

[0166] Step S169: During the tracing process, record the key preceding event nodes that contribute more than the contribution threshold to the final scene. The contribution is determined by the probability of the node occurring in the deduction and its weight in the impact on subsequent events.

[0167] Specifically, on the backtracking path, each node (event) has a contribution score. This contribution score can be defined as the probability of the node's occurrence multiplied by the weights of all edges on the path leading to the final event. A contribution threshold, TH_contribution, is set. During the backtracking process, only nodes with a contribution score greater than TH_contribution are recorded and marked as "critical event fragments." For example, the initial "smoke alarm" node, although having a high probability of occurrence, would not lead to the final high-impact scenario if it were not coupled through the "illegal access control" node. Therefore, the contribution score of the "illegal access control" node might be higher, and it would be recorded.

[0168] Step S1610: Arrange all key preceding event nodes in the order of their activation in the deduction rounds to form a sequence of key logical segments from the initial perturbation to the final scenario.

[0169] Specifically, all the key nodes recorded in step S169 are sorted in ascending order according to their actual occurrence in the parallel simulation (from 0 to K), resulting in a sequence. For example, Sequence_1 = [(Round 0, laboratory smoke alarm), (Round 1, library unauthorized entry), (Round 2, forced unlocking of access control), ..., (Round 3, panic due to crowd gathering)]. This sequence clearly demonstrates the complete causal chain of how the initial anomalous signal evolves step by step into the representative future security scenario RepScene_1.

[0170] Step S1611: Analyze the type, location, and temporal relationship of event nodes in the sequence of key event fragments, and extract the core evolutionary pattern and key turning point that leads to the occurrence of this representative future security scenario.

[0171] Specifically, a pattern analysis was performed on Sequence_1. For example, it was found that all events in the sequence occurred within the "library-laboratory" complex, and were very closely spaced in time. The "illegal access control" event was found to be the bridge connecting the physical fire spread and the logical security failure, and can be defined as the "critical turning point" in the evolution of this scenario. The core evolutionary pattern can be summarized as: "The laboratory fire triggers a logical linkage, leading to the failure of the library's access control system, which in turn causes panic and the risk of a stampede."

[0172] Step S1612: Package the description of representative future security scenarios, their average probability of occurrence, average degree of impact, corresponding key logical fragment sequences and core evolution patterns into a target deduction conclusion package.

[0173] Specifically, all the above analysis results, including the description text of RepScene_1 (such as "stampede accident caused by library fire"), P_avg_1, Impact_avg_1, key event fragment sequence Sequence_1, core evolution pattern text, and possible on-site diagrams, are uniformly packaged into a structured data package called the "target deduction conclusion package" for use by the subsequent early warning and response instruction generation module.

[0174] Step S170: Based on the key event sequence and the future security scenario, generate a set of campus security early warning and handling instructions with specific execution objects, execution actions, execution locations and execution times.

[0175] Step S171: Analyze the sequence of key reasoning segments, calculate the blockability and timeliness of each reasoning segment in the sequence based on the predefined intervention utility rule base, and determine the reasoning segment with the highest comprehensive score as the primary intervention point.

[0176] Specifically, an intervention utility rule base is loaded. This rule base defines intervention measures and their expected utility for different types of event segments. For example, for the "laboratory smoke alarm" segment, the rule base defines its blockability score as 0.2 (because a fire has already occurred, it is difficult to block) and its timeliness score as 0.9 (a response is required in a very short time). For the "library intrusion" segment, the blockability score is 0.8 (it can be stopped by remotely locking the door, dispatching security guards, etc.), and the timeliness score is 0.6. The comprehensive score for each segment is calculated as Score_intervention = α_block. Blockability +β_timely Timeliness. The highest-scoring segment, such as "illegal trespassing in the library," is selected as the "primary intervention point." This means that successful intervention at this point will, to the greatest extent possible, prevent the situation from escalating to the worst-case scenario.

[0177] Step S172: Match predefined atomic response actions from the contingency plan knowledge base according to the event type and entity attributes corresponding to the primary intervention point.

[0178] Specifically, the contingency plan knowledge base stores standardized response actions for various events, called "atomic response actions." For example, for an "illegal intrusion" event, the atomic response actions matched in the contingency plan database are "remote access control" and "on-site personnel verification." For a "smoke alarm," the atomic response actions are "fire sprinkler activation" and "personnel evacuation guidance."

[0179] Step S173: Based on the impact range and average impact of the future security scenario, query the response level mapping table to determine the corresponding response level.

[0180] Specifically, the response level mapping table maps the scope and degree of impact of a scenario to different response levels. For example, if the impact of a future security scenario RepScene_1 covers the entire library and the average impact level Impact_avg_1 is 0.8 (high), then querying the mapping table will yield a response level of "Level 1 Response (Campus Level)". If the impact is limited to a single room and the degree of impact is low, it may be "Level 3 Response (Local)".

[0181] Step S174: Based on the response level, the matched atomic response action is instantiated into a specific response task; the instantiation process includes: according to the type of atomic response action, calling the corresponding resource allocation rule to determine the task execution object from the campus security personnel database, equipment resource database, or management interface; according to the definition of the atomic response action, generating a task execution instruction containing the operation object, action command, and necessary parameters; extracting location information from the primary intervention point and its related event fragments as the task execution location; and calculating and generating the expected time window for task execution based on the timeline of the future security scenario.

[0182] Specifically, for the primary intervention point "illegal intrusion into the library," the matched atomic response action is "remote access control." Based on the resource allocation rules for "remote access control," the access controller device ID responsible for library entrance A, "AccessCtrl_Lib_A," is found in the device resource library. The generated task execution instruction is {Operation object: "AccessCtrl_Lib_A", Action command: "Lock", Required parameter: "lock_duration=300 seconds"}. The execution location is extracted from the event fragment of the primary intervention point, namely "library entrance A." Based on the timeline of future security scenario projections, the worst-case scenario is expected to occur in 10 minutes; therefore, the task is expected to complete within 1 minute, forming the expected time window "T_deadline = current time + 1 minute".

[0183] Step S175: The response tasks generated for the primary intervention points are added to the campus safety early warning and response instruction set as first-level instructions.

[0184] Specifically, the task instantiated in step S174 is encapsulated into a structured instruction, such as {Instruction ID: "CMD_001", Priority: "Level 1", Type: "Access Control", Execution Object: "AccessCtrl_Lib_A", Action: "Lock", Location: "Library Entrance A", Expected Completion Time: "T_now+60s"}, and added to the instruction set OrderSet.

[0185] Step S176: For the key reasoning fragment nodes in the sequence of key reasoning fragments, excluding the primary intervention point, sort them according to their comprehensive scores, and repeat the steps from matching atomic response actions to generating response tasks in sequence to generate secondary intervention tasks, which are then added to the instruction set as secondary instructions.

[0186] Specifically, for the remaining nodes in the key event sequence Sequence_1, they are sorted from high to low according to their comprehensive scores calculated in step S171. Then, for each node (e.g., "laboratory smoke alarm"), steps S172 to S174 are repeated to generate the corresponding response task. For example, for "laboratory smoke alarm", instructions to "start sprinkler system" and "evacuate laboratory personnel" are generated. These instructions are assigned a "secondary" priority and added to the instruction set OrderSet.

[0187] Step S177: Perform resource conflict and logical consistency checks on the generated response tasks at all levels, sort them according to task priority and expected time window, and generate a campus security early warning and response instruction set.

[0188] Specifically, examine all instructions in the OrderSet. For example, check if two instructions require the same device to perform a mutually exclusive operation (such as simultaneously "locking" and "unlocking" the same access control). If a conflict is found, resolve it according to priority and logical rules (e.g., higher-priority instructions override lower-priority instructions). Check logical consistency; for example, ensure that the "evacuate the laboratory" instruction executes after the "start the sprinkler" instruction, or that the two can be executed concurrently. After verification, sort all instructions according to priority (Level 1 > Level 2) and, within each priority level, according to the urgency of the expected time window.

[0189] Step S178: Encapsulate the campus security early warning and response instruction set into a standard instruction message and distribute it through the campus communication network to the security terminal, equipment control system or management platform associated with the corresponding task execution object.

[0190] Specifically, the sorted instruction set (OrderSet) is encapsulated according to standard communication protocols (such as MQTT, HTTP) to form instruction messages. Then, through the campus network, the "lock access control" instruction is sent to the access control controller's interface, the "start sprinkler system" instruction is sent to the fire protection system's control platform, and the "evacuate personnel" warning information is sent to security personnel's handheld terminals and the area's broadcast system. Thus, a complete closed-loop process from data acquisition, event analysis, deduction and prediction to instruction generation is completed.

[0191] Figure 2 This application illustrates a campus security situation assessment and early warning system 100 based on multi-source data fusion, comprising a processor 1001, a memory 1003, and program code stored in the memory 1003. The processor 1001 executes the program code to implement the steps of the campus security situation assessment and early warning method based on multi-source data fusion.

[0192] The memory 1003 is used to store program code for executing the embodiments of this application, and its execution is controlled by the processor 1001. The processor 1001 is used to execute the program code stored in the memory 1003 to implement the steps shown in the foregoing method embodiments.

[0193] This application provides a computer-readable storage medium storing program code, which, when executed by a processor, can implement the steps and corresponding content of the aforementioned method embodiments.

[0194] The above description is only an optional implementation method for some implementation scenarios of this application. It should be noted that for those skilled in the art, other similar implementation methods based on the technical concept of this application, without departing from the technical concept of this application, also fall within the protection scope of the embodiments of this application.

Claims

1. A method for campus security situation assessment and early warning based on multi-source data fusion, characterized in that, The method includes: Collect multi-source data streams within the campus, and parse discrete security-related event fragments from the multi-source data streams in real time. The multi-source data streams include video surveillance data streams, IoT sensor data streams, information system log data streams, and access control data streams. The aforementioned safety-related factual fragments are matched and associated with a pre-built campus factual knowledge base to construct a campus factual network diagram that reflects the interaction logic of people, things, and events within the campus. Based on the campus event network diagram, real-time perceived abnormal event fragments are injected as initial disturbances to drive the simulation and deduction model, which combines physical laws, to conduct event propagation and deduction in the virtual space represented by the campus event network diagram. Based on the campus event network diagram, the same initial disturbance is injected to drive the constraint deduction model combined with logical rules to perform condition constraint propagation deduction in the logical relationship represented by the campus event network diagram. By integrating the physical propagation path output by the simulation model with the logical constraint state output by the constraint model, multiple rounds of parallel simulations are performed to generate a set of simulation scenario snapshots describing the campus safety status at different future points in time. The state analysis and scenario convergence processing of the simulated scenario snapshot set are performed. Key scenarios of concern are selected based on preset thresholds, and representative future security scenarios are generated through cluster analysis. Then, the key event fragment sequences that led to the occurrence of each representative future security scenario are traced back in reverse. Based on the sequence of key event fragments and the future security scenario, a set of campus security early warning and response instructions with specific execution objects, execution actions, execution locations and execution times is generated.

2. The campus security situation assessment and early warning method based on multi-source data fusion according to claim 1, characterized in that, The step of parsing discrete security-related event fragments from the multi-source data stream in real time includes: Frame-by-frame behavior analysis is performed on video surveillance data streams to identify the motion trajectory, stationary behavior, interactive behavior and abnormal action patterns of targets in the video footage. The target's identity, behavior category, occurrence time, camera location coordinates and behavior feature parameters are combined into video event segments. Threshold and pattern judgments are performed on IoT sensor data streams to identify abnormal states such as sensor readings exceeding safety thresholds, sudden changes in sensor readings, and interruption of sensor data. Sensor device identification, abnormal type, abnormal reading, abnormal start time, abnormal end time, and sensor physical location are combined into IoT event fragments. Clustering and sequence analysis are performed on information system log data streams to identify abnormal login behavior, abnormal data access behavior, abnormal process call behavior, and abnormal network connection behavior. User identifier, source address, destination address, operation type, operation timestamp, and risk level are combined into information event fragments. The access control data stream is analyzed by rules and frequency to identify illegal intrusion events, tailgating events, abnormal access events, and high-frequency abnormal access events. The access personnel identification, access point location, access timestamp, access result, and abnormal flag are combined into access control event fragments. Define a unified data structure for video data segments, IoT data segments, information data segments, and access control data segments. This data structure includes subject elements, action elements, object elements, time elements, space elements, and attribute elements. The video logic segments, IoT logic segments, information logic segments, and access control logic segments obtained from the parsing are standardized in format according to the unified logic segment data structure to generate standard logic segments. The standard logical fragments are semantically disambiguated and normalized, and the action element words that express the same semantics in different data sources are mapped to specific words in the standard action lexicon. Synonymous location descriptions are mapped to standard location coordinates or regional codes. Assign a globally unique logic fragment identifier to each standard logic fragment that has undergone semantic normalization, and output the standard logic fragment carrying the logic fragment identifier as a security-related logic fragment. Establish a cache queue for security-related event fragments, store newly generated security-related event fragments in chronological order, set a cache time window, and remove historical security-related event fragments that exceed the time window.

3. The campus security situation assessment and early warning method based on multi-source data fusion according to claim 1, characterized in that, The process of matching and associating the safety-related event fragments with a pre-built campus event knowledge base to construct a campus event network diagram reflecting the interaction logic of people, things, and events within the campus includes: Load a pre-built campus event knowledge base, which includes an entity database, an event database, and a relationship rule database. The entity database stores personnel entities, equipment entities, location entities, system entities and their attributes. The event database stores typical security event templates. The relationship rule database stores physical association rules, logical association rules and causal association rules between entities. Match safety-related factual fragments with the entity database in the campus factual knowledge base, identify the entity identifiers corresponding to the subject and object elements in the safety-related factual fragments, and if there is no completely matching entity, create a new entity node and supplement the attributes of the new entity node. Match safety-related incident fragments with the event database in the campus incident knowledge base, calculate the similarity between safety-related incident fragments and each typical safety event template in terms of action elements and attribute elements, and classify safety-related incident fragments with similarity exceeding the threshold into the corresponding event type; Taking safety-related event fragments as the core, and based on their time and space elements, the spatiotemporal association rules are searched in the relational rule base of the campus event knowledge base to establish spatiotemporal association edges between the safety-related event fragment and other safety-related event fragments with similar time and adjacent space. Taking safety-related incident fragments as the core, and based on their subject elements, action elements, and object elements, logical causal rules are searched in the relational rule base of the campus incident knowledge base to establish causal relationship edges between the safety-related incident fragment and other safety-related incident fragments that may lead to its occurrence or may lead to it. Each spatiotemporal related edge is assigned a weight based on temporal proximity and spatial proximity. Temporal proximity is calculated based on the time difference between security-related factual segments, and spatial proximity is calculated based on the spatial distance between security-related factual segments. Each causal relationship edge is assigned a causal confidence score as a weight. The causal confidence score is calculated based on the frequency of the corresponding causal relationship in historical data and the confidence factor of the rule in the rule base. By integrating all safety-related factual fragments as nodes and all spatiotemporal and causal related edges as edges, a weighted directed graph structure is constructed, which is the initial campus factual network graph. Redundant edges are eliminated from the initial campus event network graph, the processed weighted directed graph structure is persistently stored, and a dynamic update interface for event fragments related to real-time security is established.

4. The campus security situation assessment and early warning method based on multi-source data fusion according to claim 1, characterized in that, The simulation model, which combines physical laws with the driving force, performs event propagation simulations in the virtual space represented by the campus event network diagram, including: From real-time perceived security-related event segments, abnormal event segments marked as abnormal are filtered out. These abnormal event segments include abnormal actions in video event segments, device failures in IoT event segments, network attacks in information event segments, and unauthorized intrusions in access control event segments. Select one or more of the abnormal event fragments as initial perturbation fragments, map the initial perturbation fragments to the corresponding nodes in the campus event network graph, activate the nodes, and mark their states as having occurred; Based on the event type of the initial disturbance segment, the corresponding event physical propagation model is matched from the physical law library, which includes crowd flow model, information diffusion model, fault propagation model, and fire spread model; Input the spatial elements of the nodes in the campus event network diagram, campus geographic information data, and current environmental parameters into the matching event physics propagation model, and initialize the parameters of the event physics propagation model; Based on the physical propagation model of events, the influence intensity of an activated node on its neighboring nodes in physical space is calculated. The influence intensity is determined by the physical distance attenuation factor, the medium blocking factor, and the energy attenuation factor. Based on the influence intensity and the weights of the edges in the campus event network graph, the physical trigger probability of neighboring nodes being triggered at the physical level is calculated. The physical trigger probability is a function of the influence intensity and the weights of the spatiotemporally related edges. Monte Carlo simulation or deterministic threshold judgment is used to determine whether neighboring nodes are activated at the physical level based on the physical trigger probability, and newly activated nodes are added to the set of nodes that have occurred. The newly activated node is used as the source point for a new round of deduction. The steps from matching the physical propagation model of the event to deciding whether the node is activated are repeated to perform iterative deduction of physical propagation. Record the newly activated nodes and their activation rounds in each iteration to form an event propagation path based on physical laws. The event propagation path is a sequence of nodes arranged in chronological order. When the iterative simulation reaches the preset maximum number of rounds, or when no new nodes are activated in a new round of simulation, the physical propagation simulation is terminated, and the final event propagation path and the physical trigger probability and round information of each node being activated are output.

5. The campus security situation assessment and early warning method based on multi-source data fusion according to claim 1, characterized in that, The constraint deduction model, which combines driving logic rules, performs condition constraint propagation deduction in the logical relationships represented by the campus event network graph, including: From real-time perceived security-related event segments, abnormal event segments marked as abnormal are filtered out. These abnormal event segments include abnormal actions in video event segments, device failures in IoT event segments, network attacks in information event segments, and unauthorized intrusions in access control event segments. Select one or more of the abnormal event fragments as initial constraint perturbation fragments, and map the initial constraint perturbation fragments to the corresponding nodes in the campus event network graph, marking the state of the nodes as condition satisfied or condition violated; Load logical constraint rules related to the nodes of the campus event network graph from the logical rule base. The logical rule base includes state dependency rules, resource contention rules, time sequence constraint rules, and permission constraint rules. Traverse the campus network diagram to find all logical constraint rules that take the current state of the marked node as a prerequisite, and form a set of rules to be evaluated. For each rule in the set of evaluation rules, check whether all its preconditions are met. If all are met, trigger the rule and execute the conclusion action of the rule. The conclusion action may be to activate a new node, disable a node, or modify the node attributes. If the conclusion of a rule is to activate a new node, then the logical activation confidence of that new node is calculated at the logical level. The logical activation confidence is calculated based on the confidence of the rule itself and the degree to which the preconditions are met. If the conclusion of a rule is to prohibit a node, then the state of that node is marked as logically prohibited, and the possibility of it being activated by other rules is reduced. The newly added state nodes, logically prohibited nodes, and modified attributes affected by the rules triggered in this round are treated as new constraint changes, and the states of the corresponding nodes in the campus event network graph are updated. Using the newly added state node as a new condition, the steps from finding the set of rules to be evaluated to updating the node state are repeatedly executed to perform iterative propagation and deduction of logical constraints. Record the nodes where the state changes, the type of change, and the rules that trigger the change in each round of logical deduction to form a logical constraint propagation chain, which describes the derivation process of logical state changes; When the logical deduction reaches a stable state, the logical constraint propagation deduction is terminated, and the final logical state of each node and the logical constraint propagation chain are output. The stable state is used to reflect when no new rules are triggered or the node state no longer changes.

6. The campus security situation assessment and early warning method based on multi-source data fusion according to claim 1, characterized in that, The simulation model outputs the physical propagation path, and the constraint model outputs the logical constraint state. Multiple rounds of parallel simulations are then performed to generate a set of snapshots of simulated scenarios describing the campus security status at different future points in time, including: During the simulation initialization phase, the total number of parallel simulation rounds and the time step of each round are set, and an empty set of simulation scene snapshots is initialized. For the first round of simulation, the list of nodes activated in the first round of simulation in the physical propagation path output by the simulation model is merged with the list of nodes whose state changes in the first round of simulation in the logical constraint state output by the constraint simulation model. During the fusion process, the same node in both node lists is checked. If the node is activated in the physical propagation path and is allowed to be activated in the logical constraint state, then the node is identified as a security event that occurred after the first round of simulation. If a node is only activated in the physical propagation path but is marked as logically prohibited in the logical constraint state, then the node is suppressed and not counted as a security event. If a node is activated in a logically constrained state but is not within the coverage area of ​​the physical propagation path, it is necessary to evaluate it by combining the spatial attributes of the node with the residual effects of the physical propagation model, and determine whether it has occurred with a certain probability. Determine the set of security event nodes that will be triggered after the first round of simulation, and the estimated probability of occurrence of each event node; Based on the set of triggered event nodes, the state of the nodes in the campus event network graph is updated, and a snapshot of the campus security status after the first round of simulation is generated. The campus security status snapshot includes the currently occurring events, event locations, event probabilities, and an assessment of the overall risk level of the campus. Add the snapshot of the campus security status after the first round of simulation to the simulation scenario snapshot set; take the snapshot of the campus security status after the first round of simulation as the new initial state, feed the new initial state back to the simulation model and the constraint simulation model, and start the second round of simulation; The simulation model continues the physical propagation simulation based on the new set of already occurred event nodes, and outputs the second round of physical propagation path; the constraint simulation model continues the logical constraint propagation simulation based on the new node states, and outputs the second round of logical constraint states. Repeat the steps from merging the two lists to generating a state snapshot to complete the second round of simulation. Generate a campus security state snapshot after the second round of simulation and add it to the simulation scenario snapshot set until the preset total number of simulation rounds is reached. Finally, generate a set of simulation scenario snapshots arranged in chronological order, with each snapshot describing the campus security state at the corresponding future point in time.

7. The campus security situation assessment and early warning method based on multi-source data fusion according to claim 1, characterized in that, The process involves performing state analysis and scenario convergence processing on the set of simulated scenario snapshots, filtering out key scenarios based on preset thresholds, generating representative future security scenarios through cluster analysis, and then tracing back the key event sequence that led to the occurrence of each representative future security scenario, including: For each simulation scenario snapshot in the simulation scenario snapshot set, extract the list of security event nodes that have occurred, the probability of occurrence of each event node, and the overall risk level assessment value of the campus. Calculate the probability of scenario occurrence for each snapshot of the scenario, which is approximately obtained by the joint probability of all event nodes that have occurred in the snapshot; Calculate the scene impact degree of each simulation scenario snapshot, which is the weighted sum of the preset severity levels of all event nodes that have occurred in the snapshot; at the same time, obtain the overall campus risk level assessment value of the simulation scenario snapshot; With the probability of a scenario occurring as the horizontal axis and the degree of the scenario's influence as the vertical axis, all snapshots of the inferred scenarios are plotted on a two-dimensional plane of probability influence. On the two-dimensional plane of probability influence, based on the preset probability judgment threshold and influence degree judgment threshold, the inferred scene snapshots with a scene occurrence probability greater than the probability judgment threshold or a scene influence degree greater than the influence degree judgment threshold are selected as the preliminary candidate scene set; Cluster analysis based on event node characteristics, occurrence probability and impact degree is performed on the preliminary candidate scenario set, and scenarios in the same cluster in the clustering results are grouped into the same representative future security scenario; Calculate the average probability of occurrence and average impact of each representative future security scenario, and sort them according to the average impact. For each representative future security scenario, starting from the snapshot of the scenario that constitutes the representative future security scenario, we trace back the preceding event nodes that led to the state of the representative future security scenario along the reverse path of parallel deduction. During the tracing process, key preceding event nodes that contribute more than a contribution threshold to the final scenario are recorded. The contribution is determined by the probability of the node occurring in the deduction and its weight in the impact on subsequent events. Arrange all key preceding event nodes in the order of their activation in the deduction rounds to form a sequence of key logical fragments from the initial disturbance to the final scenario; By analyzing the type, location, and temporal relationship of event nodes in the sequence of key event fragments, the core evolutionary patterns and key turning points that lead to the occurrence of this representative future security scenario are extracted. The descriptions of representative future security scenarios, their average probability of occurrence, average impact, corresponding key logical segments, and core evolution patterns are packaged together to form a target deduction conclusion package.

8. The campus security situation assessment and early warning method based on multi-source data fusion according to claim 1, characterized in that, Based on the sequence of key event fragments and the future security scenario, a set of campus security early warning and response instructions is generated, which includes specific execution objects, execution actions, execution locations, and execution times. The sequence of key reasoning fragments is analyzed, and based on a predefined intervention utility rule base, the blockability and timeliness of each reasoning fragment in the sequence are calculated. The reasoning fragment with the highest comprehensive score is identified as the primary intervention point. Based on the event type and entity attributes corresponding to the primary intervention point, match predefined atomic response actions from the contingency plan knowledge base; Based on the impact scope and average impact of the future security scenario, query the response level mapping table to determine the corresponding response level; Based on the response level, the matched atomic response actions are instantiated into specific response tasks. The instantiation process includes: according to the type of atomic response action, calling the corresponding resource allocation rules to determine the task execution object from the campus security personnel database, equipment resource database, or system management interface; according to the definition of the atomic response action, generating a task execution instruction containing the operation object, action command, and necessary parameters; extracting location information from the primary intervention point and its related event fragments as the task execution location; and calculating and generating the expected time window for task execution based on the timeline of the future security scenario. The response tasks generated for the primary intervention points will be treated as first-level instructions and added to the campus safety early warning and response instruction set. For the key logic fragment nodes in the sequence of logic fragments other than the primary intervention point, based on their comprehensive scores, the steps from matching atomic response actions to generating response tasks are repeatedly executed to generate secondary intervention tasks, which are then added to the instruction set as secondary instructions. Resource conflict and logical consistency checks are performed on the generated response tasks at all levels. The tasks are sorted according to their priority and expected time window to generate a campus security early warning and response instruction set. The campus security early warning and response instruction set is encapsulated into a standard instruction message and distributed to the security terminal, equipment control system or management platform associated with the corresponding task execution object through the campus communication network.

9. The campus security situation assessment and early warning method based on multi-source data fusion according to claim 3, characterized in that, The process of matching safety-related event fragments with the event database in the campus event knowledge base, calculating the similarity between the safety-related event fragments and each typical safety event template in terms of action elements and attribute elements, and classifying safety-related event fragments with similarity exceeding a threshold into the corresponding event type includes: Read a typical safety event template from the campus event knowledge base. The typical safety event template defines the standard action element values ​​and standard attribute element value ranges for the corresponding event type. Extract the actual values ​​of action elements from the safety-related event fragments to be matched, and calculate the semantic similarity with the standard action element values ​​of typical safety event templates to obtain the action element similarity score. Extract the actual values ​​of the attribute elements of the security-related event fragments to be matched, and calculate the matching degree with the standard attribute element value range of the typical security event template to obtain the attribute element matching degree score; Based on the predefined weights of the event template, the similarity scores of action elements and the matching scores of attribute elements are weighted and summed to calculate the comprehensive matching score between the security-related event fragment and the typical security event template. Iterate through all typical security event templates in the event database, and repeatedly execute the steps from reading typical security event templates to calculating the comprehensive matching score to obtain a list of comprehensive matching scores between the security-related event fragment and all event templates; Find the highest score from the comprehensive matching score list. If the highest score exceeds the preset classification similarity threshold, then classify the security-related logical fragment into the event type corresponding to the highest score. If the highest score does not exceed the classification similarity threshold, a new event type is created for the security-related logical fragment, and the security-related logical fragment is stored in the event library as the initial template of the new event type. At the same time, the security-related logical fragment is classified under the new event type. The system labels security-related event fragments categorized under event types with event type tags, records the matching score of each security-related event fragment with its event type, and repeats the steps from reading the first typical security event template to recording the matching score for all newly generated security-related event fragments, thus completing the real-time matching and categorization of security-related event fragments with the event database.

10. A campus security situation assessment and early warning system based on multi-source data fusion, characterized in that, The method includes a processor and a computer-readable storage medium storing machine-executable instructions, which, when executed by the processor, implement the campus security situation assessment and early warning method based on multi-source data fusion as described in any one of claims 1-9.

Images