Event processing method and program product, storage medium, electronic device

Abstract

This application discloses an event handling method, program product, storage medium, and electronic device. The method includes: acquiring a first message multicast by a probe device requesting processing of a first event; parsing the first message to obtain a first event type and a first group identifier for the first event included in the first message; and, if the first event type is determined to be a target type, and the execution device and the probe device are determined to be in the same multicast group based on the first group identifier, executing a first processing action by the execution device. This application solves the problem in related technologies where events cannot be processed promptly in the event of a central server malfunction, thereby achieving the effect that the execution device can still process events promptly without relying on a central server.

Description

Technical Field

[0001] This application relates to the field of distributed control, and more specifically, to an event processing method and program product, storage medium, and electronic device. Background Technology

[0002] In related technologies, event processing systems commonly adopt a star topology based on a central server. For example, when processing a fire alarm event, the fire detection devices in the system send alarm information to the central server via wired or other means. The central server then uniformly parses the event type, determines the linkage logic, and issues control commands to the executing devices to achieve fire-fighting linkage (such as activating smoke exhaust valves and closing fireproof roller shutters). The operation of this architecture is highly dependent on the continuous online presence and stable response of the central server. Once the central server malfunctions due to network interruption, hardware failure, software crash, or attack, the entire event processing system will be paralyzed.

[0003] There is currently no effective solution to the technical problem of being unable to process events in a timely manner when the central server is malfunctioning. Summary of the Invention

[0004] This application provides an event handling method and program product, storage medium, and electronic device to at least solve the problem in the related art of being unable to handle events in a timely manner when the central server is abnormal.

[0005] According to one aspect of the embodiments of this application, an event processing method is provided, comprising: acquiring a first message multicast by a probe device requesting processing of a first event; parsing the first message to obtain a first event type and a first group identifier of the first event included in the first message, wherein the first group identifier is used to identify the multicast group in which the probe device is located; and, if the first event type is determined to be a target type, and an execution device is determined to be in the same multicast group as the probe device based on the first group identifier, performing a first processing action by the execution device, wherein the execution device has the capability to process events of the target type, and the first processing action includes the action of processing the first event.

[0006] In an exemplary embodiment, before determining the first message multicast by the probe device requesting processing of the first event, the method further includes: determining a first multicast packet address corresponding to the second packet identifier from a first mapping relationship based on a pre-allocated second packet identifier, wherein the first mapping relationship is used to indicate the mapping relationship between the packet identifier and the multicast packet address, and the second packet identifier is also used to identify the first multicast packet corresponding to the first multicast packet address; sending a first request to a communication device to request that the execution device be added to the first multicast packet; receiving a first response sent by the communication device in response to the first request; and determining that the execution device has established a multicast connection with the probe device if the first response indicates that the communication device allows the execution device to join the first multicast packet, wherein the transmission of multicast messages is allowed among multiple devices under the multicast connection.

[0007] In an exemplary embodiment, parsing the first message to obtain the first event type and first group identifier of the first event included in the first message includes: performing a verification operation on the first message, wherein the verification operation includes at least one of the following: verifying whether the protocol header in the first message is in a preset format; verifying whether the fields in the first message match preset rules; if the first message includes a checksum field, comparing whether a first value calculated by the execution device using a target algorithm is consistent with a second value in the checksum field to determine the integrity of the first message, wherein the second value is a value calculated by the detection device using the target algorithm; if the verification of the first message is determined to be successful, parsing the first message to obtain the occurrence time of the first event; and if the occurrence time is within a preset time period, extracting the first event type and the group identifier from the first message.

[0008] In one exemplary embodiment, the method further includes: receiving a control instruction sent by a target server, wherein the control instruction is generated by the target server based on a second message sent by the detection device and sent when the first event is detected to have not been processed within a preset time interval, the second message including a message unicast to the target server when the detection device multicasts the first message, the second message being used to request the target server to process the first event; responding to the control instruction to start an execution component included in the execution device; and after determining that the execution component has been started, performing a second processing action through the execution component, wherein the second processing action includes an action to process the first event.

[0009] In one exemplary embodiment, obtaining a first message multicast by a detection device for requesting processing of a first event includes: receiving a plurality of third messages multicast by the detection device; if the event types of each event included in the plurality of third messages include a second event type, determining that the detection device has malfunctioned, and determining the fault time of the detection device malfunction based on the occurrence time of the event of the second event type; if the event types of each event included in the plurality of third messages include the first event type, determining a first target message included in the plurality of third messages as the first message, wherein the occurrence time of the event of the first event type included in the first target message is earlier than the fault time.

[0010] In one exemplary embodiment, after receiving the plurality of third messages multicast by the aforementioned detection device, the method further includes: if the event type of each event included in the plurality of third messages does not include the aforementioned second event type, then all of the plurality of third messages are determined to be the aforementioned first message.

[0011] In one exemplary embodiment, obtaining a first message multicast by a detection device for requesting processing of a first event further includes: receiving messages multicast by multiple detection devices to obtain multiple fourth messages; wherein the event type of each event included in the multiple fourth messages includes the first event type, and a second target message included in the multiple fourth messages for requesting processing of an event of the first event type is multicast by a target detection device, the second target message is determined as the first message, wherein the target detection device is a normally operating device.

[0012] According to another aspect of the embodiments of this application, a message multicast method is also provided, including: multicasting a first message, wherein the first message is used to request an execution device to process a first event, the first message includes a first event type of the first event and a first group identifier, the first group identifier is used to identify the multicast group in which the detection device is located, the execution device is used to perform a first processing action when it is determined that the first event type is a target type, and the execution device and the detection device are located in the same multicast group based on the first group identifier, the execution device has the ability to process the event of the target type, and the first processing action includes the action of processing the first event.

[0013] In one exemplary embodiment, prior to the multicast first message, the method further includes: determining a second multicast packet address corresponding to the first packet identifier from a second mapping relationship based on a pre-allocated first packet identifier, wherein the second mapping relationship is used to indicate the mapping relationship between the packet identifier and the multicast packet address, and the first packet identifier is used to identify the second multicast packet corresponding to the second multicast packet address; sending a second request to a communication device to request that the probe device be added to the second multicast packet; receiving a second response from the communication device in response to the second request; and determining that the probe device has established a multicast connection with the execution device if the second response indicates that the communication device allows the probe device to join the second multicast packet, wherein the transmission of multicast messages is permitted among multiple devices under the multicast connection.

[0014] According to another aspect of the embodiments of this application, an execution device is also provided, comprising: an acquisition module, configured to acquire a first message multicast by a probe device requesting processing of a first event; a parsing module, configured to parse the first message to obtain a first event type and a first group identifier of the first event included in the first message, wherein the first group identifier is used to identify the multicast group in which the probe device is located; and an execution module, configured to perform a first processing action through the execution device when it is determined that the first event type is a target type and the execution device and the probe device are located in the same multicast group based on the first group identifier, wherein the execution device has the capability to process events of the target type, and the first processing action includes the action of processing the first event.

[0015] According to another aspect of the embodiments of this application, a detection device is also provided, including: a multicast module for multicasting a first message, wherein the first message is used to request an execution device to process a first event, the first message including a first event type of the first event and a first group identifier, the first group identifier being used to identify the multicast group in which the detection device is located, the execution device being used to perform a first processing action when it is determined that the first event type is a target type, and the execution device and the detection device are located in the same multicast group based on the first group identifier, the execution device having the ability to process events of the target type, the first processing action including the action of processing the first event.

[0016] According to another aspect of the embodiments of this application, an event processing system is also provided, including an execution device as provided in the above embodiments, a detection device as provided in the above embodiments, and a communication device, wherein the execution device, the communication device, and the detection device are connected in sequence, and the communication device is used to establish a multicast connection between the execution device and the detection device, and multicast messages are allowed to be transmitted between multiple devices under the multicast connection.

[0017] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored therein, wherein the computer program is configured to perform the steps in any of the above method embodiments when executed by a processor.

[0018] According to another aspect of the embodiments of this application, a computer program product or computer program is provided, the computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, causing the computer device to perform the steps in any of the method embodiments described above.

[0019] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to perform the steps of any of the above method embodiments through the computer program.

[0020] This application eliminates the reliance on a central server for the detection device. Instead, it sends a first message, including the first event type and the first group identifier, to the execution device via multicast. Upon receiving the first message, the execution device can parse it to obtain the first event type and the first group identifier without communicating with any remote server. It then locally performs a dual check: the execution device and the detection device are in the same multicast group, and the first event type is the target type. If both conditions are met, the execution device performs a first processing action to handle the first event. The entire process is executed locally by the execution device without relying on any central server. Therefore, it solves the problem in related technologies where events cannot be processed promptly in the event of a central server malfunction. This achieves the technical effect of improving event processing efficiency by enabling the execution device to process events promptly without relying on a central server. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of the structure of an event processing system according to an embodiment of this application;

[0022] Figure 2This is a flowchart illustrating an event handling method according to an embodiment of this application;

[0023] Figure 3 This is a structural diagram of a fire alarm system in related technologies;

[0024] Figure 4 This is a flowchart illustrating a method for handling fire alarm events according to an embodiment of this application;

[0025] Figure 5 This is a flowchart illustrating a message multicast method according to an embodiment of this application;

[0026] Figure 6 This is a schematic flowchart of a method for handling fire events in an event handling system according to an embodiment of this application;

[0027] Figure 7 This is a structural block diagram of an execution device according to an embodiment of this application;

[0028] Figure 8 This is a structural block diagram of a detection device according to an embodiment of this application;

[0029] Figure 9 This is a computer system architecture block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0030] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present application. Furthermore, in the absence of conflict, the various embodiments and features in the embodiments of the present application can be arbitrarily combined with each other in principle.

[0031] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0032] According to one aspect of the embodiments of this application, an event handling method is provided. The event handling method described above can be applied to, but is not limited to, events such as... Figure 1 The event processing system shown includes a detection device 102, an execution device 104, and a communication device 106. The detection device 102 can be connected to the execution device 104 via the communication device 106, which is used to establish a multicast connection between the execution device 104 and the detection device 102, wherein multiple devices under the multicast connection are allowed to transmit multicast messages.

[0033] The aforementioned communication equipment 106 includes, but is not limited to, switches, Layer 3 routers, and smart gateways. Detection equipment 102 includes, but is not limited to, various detectors and cameras. Execution equipment 104 is a smart terminal with local event processing capabilities, including, but not limited to: fire alarm control modules, building automation controllers, edge computing nodes, and mobile terminal applications.

[0034] Taking the event handling method of this application embodiment as an example, which is executed by the execution device 104, Figure 2 This is a flowchart illustrating an event handling method according to an embodiment of this application, such as... Figure 2 As shown, the process of this method may include the following steps:

[0035] Step S202: Obtain the first message multicast by the detection device to request processing of the first event;

[0036] Figure 3 This is a flowchart illustrating a method for handling fire alarm events in related technologies, such as... Figure 3As shown, in related technologies, the detection device 302 must first unicast the alarm information to the central server 304, which then performs event type identification, cross-regional correlation analysis, and linkage strategy matching before finally issuing instructions to the execution device 306. This process is inevitably interrupted when the central server malfunctions, leading to delays or even complete failure in event processing. In the method provided in this embodiment, the detection device no longer searches for the central server but instead multicasts the first message to the execution device. Upon receiving this message, the execution device does not need to communicate with any remote server; it only needs to locally parse the first message to obtain the first event type and the first group identifier. It can then locally determine that the first event type is the target type (e.g., fire, manual alarm). If the detection device and the execution device are located in the same area, the first processing action (e.g., activating the audible and visual alarm, closing the fireproof roller shutter) is immediately executed.

[0037] Optionally, the event handling method in this embodiment can be applied to various scenarios requiring low-latency, decentralized, distributed intelligent control, including but not limited to applications in fire alarm systems, intelligent building automation management, industrial automation management, and rail transit tunnel management. For example, in a fire compartment of a high-rise residential building, when a smoke detector (i.e., the aforementioned detection device) detects a fire (i.e., the aforementioned first event) and broadcasts the first message, the execution devices within the same group can autonomously trigger execution actions through the fireproof roller shutter controller, smoke exhaust valve driver, and audible and visual alarm without intervention from the central server. In a factory production line, when a vibration sensor (i.e., the aforementioned detection device) detects an equipment malfunction and broadcasts an overheating event (i.e., the aforementioned first event), the execution devices within the same group can immediately respond to the overheating event through nearby emergency stop relays and ventilation systems without intervention from the central server.

[0038] Optionally, the detection device in this embodiment is an intelligent terminal deployed in the physical environment to sense specific events and possessing network communication capabilities. It can locally determine the collected physical signals (such as smoke concentration, temperature, manual triggering, etc.), and when preset conditions are met, actively construct and multicast a first message including the event type and group identifier, and store the collected data. The detection device includes, but is not limited to, smoke detectors, heat detectors, manual fire alarm buttons, gas detectors, flame detectors, water immersion sensors, or intelligent cameras with edge intelligent analysis capabilities. It should be noted that the above is merely an illustrative example, and those skilled in the art can flexibly configure the detection device according to the actual application scenario requirements.

[0039] Optionally, after collecting data, the detection device in this embodiment will first determine whether the collected data meets preset conditions. If the preset conditions are met, it will determine that a first event has occurred and send a first message. For example, in a fire alarm scenario, the preset condition could be that the smoke concentration exceeds a threshold, and the duration of the smoke concentration exceeding the threshold is not less than 5 seconds. It should be noted that the above is only an illustrative example, and those skilled in the art can flexibly design corresponding preset conditions according to the actual application scenario requirements.

[0040] Optionally, in this embodiment, the first message refers to a structured network data packet sent by the probe device via multicast. The first message includes, but is not limited to: the event type (Event_Code) of the first event, the first group identifier (Zone_ID), the device identifier (Device_ID) of the probe device, the occurrence time (Timestamp) of the first event, and the event priority (Priority_Level) used to indicate the urgency of the first event.

[0041] Step S204: Parse the first message to obtain the first event type and first group identifier of the first event included in the first message, wherein the first group identifier is used to identify the multicast group to which the detection device is located;

[0042] Optionally, the first event type in this embodiment refers to the event category with predefined semantics identified by the detection device after local judgment, which is used to distinguish triggering events of different natures (such as fire, overheating, leakage, malfunction, etc.). The first event type includes, but is not limited to, those represented by preset enumeration identifiers (such as "Fire" indicating a fire, "Overheat" indicating overheating of other monitored devices, and "GasLeak" indicating a leak of harmful gas in the area where the detection device is located).

[0043] Optionally, in this embodiment, the first group identifier is used to identify the multicast group to which the detection device belongs. Ideally, the detection device should only join one multicast group. The first group identifier includes, but is not limited to, configurations based on physical or logical boundaries such as building fire compartments, production line units, and room numbers. The first group identifier includes, but is not limited to, allocations made through factory settings, distribution from the target server, or network protocols.

[0044] Step S206: If the first event type is determined to be a target type, and the execution device and the detection device are located in the same multicast group based on the first group identifier, the execution device performs a first processing action. The execution device has the ability to process events of the target type, and the first processing action includes processing the first event.

[0045] Optionally, in this embodiment, the target type refers to a specific event type predefined in the linkage logic table stored locally by the execution device, which can trigger a processing action. The execution device only responds to events matching the "target type" and ignores events of non-target type, thereby achieving selective and conditional response. For example, if "target type = Fire" is defined in the linkage logic table stored locally by the execution device, the execution device will only respond to and process the "Fire" event. It should be noted that in actual use, an execution device can process multiple types of events (e.g., events with event types "Fire", "GasLeak", and "Overheat" can all be processed). When the execution device can process multiple types of events, it will determine the execution order of various different processing actions based on event priority (e.g., processing actions for events with higher priority are executed first). In addition, the linkage logic table may also store composite conditions, such as the execution device only executing the first processing action when the target type = "Fire" and the number of devices sending messages is ≥2. The first processing action includes, but is not limited to, obtaining it by querying the linkage logic table stored locally by the execution device or using a locally deployed model; this embodiment does not impose any limitations on this.

[0046] Optionally, in this embodiment, the first processing action refers to the action taken by the execution device to process the first event under the conditions that "the event type is the target type" and "multicast group matching" is met. This action can be a physical operation or a communication command. The first processing action includes, but is not limited to, activating an audible and visual alarm, closing a fireproof roller shutter, opening a smoke exhaust valve, cutting off non-fire-fighting power, sending a text message notification, or displaying an application pop-up window.

[0047] Optionally, the execution device in this embodiment is used to listen to messages sent by the detection devices in its own group and autonomously trigger actions to achieve distributed control without the reliance on a central server. The execution device includes, but is not limited to, audible and visual alarms, fireproof roller shutter controllers, smoke exhaust valve drivers, fire pump start modules, non-fire power cut-off devices, elevator emergency landing controllers, electromagnetic locks, gas extinguishing start devices, air conditioning fresh air system controllers, or industrial production line emergency stop relays.

[0048] In this embodiment, the detection device sends a first message, including a first event type and a first group identifier, to the execution device via multicast. Upon receiving the first message, the execution device can parse it to obtain the first event type and the first group identifier without communicating with any remote server. It then locally performs a dual check: the execution device and the detection device are in the same multicast group, and the first event type is the target type. If both conditions are met, the execution device performs a first processing action to process the first event. The entire process is executed locally by the execution device without relying on any central server. Therefore, it solves the problem in related technologies where events cannot be processed promptly in the event of a central server malfunction. This achieves the technical effect of improving event processing efficiency by enabling the execution device to process events promptly without relying on a central server.

[0049] In an exemplary embodiment, before determining the first message multicast by the probe device requesting processing of the first event, the method further includes: determining a first multicast packet address corresponding to the second packet identifier from a first mapping relationship based on a pre-allocated second packet identifier, wherein the first mapping relationship is used to indicate the mapping relationship between the packet identifier and the multicast packet address, and the second packet identifier is also used to identify the first multicast packet corresponding to the first multicast packet address; sending a first request to a communication device to request that the execution device be added to the first multicast packet; receiving a first response sent by the communication device in response to the first request; and determining that the execution device has established a multicast connection with the probe device if the first response indicates that the communication device allows the execution device to join the first multicast packet, wherein the transmission of multicast messages is allowed among multiple devices under the multicast connection.

[0050] Optionally, in this embodiment, the second group identifier refers to a unique identifier pre-assigned to a logical area (such as "East side of the 1st floor" or "Production line in area A") during the system deployment phase. It is used to logically delineate control boundaries and is a semantic name of the area, not a network address. The second group identifier includes, but is not limited to, allocation through factory settings, distribution by the target server, or network protocols.

[0051] Optionally, the first mapping relationship in this embodiment refers to a configuration table or rule set that is pre-set or dynamically maintained in the execution device, used to establish a unique mapping relationship between the group identifier (such as Zone_ID) and the corresponding IP multicast address (such as 239.XXX.1.1), and to convert the semantic zone name into a multicast group address that can be addressed by the network layer.

[0052] Optionally, in this embodiment, the communication device refers to a network node responsible for forwarding, managing, or controlling multicast membership relationships throughout the system. It possesses multicast management protocol processing capabilities, can receive and respond to multicast join requests from various devices, and decides whether to allow them to join the target multicast group. Communication devices include, but are not limited to, switches, Layer 3 routers, and smart gateways.

[0053] Optionally, in this embodiment, the first request is a network protocol message sent by the execution device to the communication device after power-on or configuration, which is used to request to join a specified multicast group. The first request includes the media access control (MAC) address or IP address of the execution device and the first multicast group.

[0054] Optionally, the first response in this embodiment is an acknowledgment or denial message (such as an Internet Group Management Protocol (IGMP) response, or an Access Control List (ACL) allow / deny message) returned by the communication device after receiving the first request, based on the device's permission policy.

[0055] Optionally, in this embodiment, the multicast connection refers to a logical communication channel established between the execution device and the probe device based on IP multicast communication after the communication device completes multicast member management. This channel allows all members within the same multicast group to send multicast messages bidirectionally or unidirectionally without requiring a point-to-point connection. In a multicast group, the probe device is the publisher node in the multicast group, and the execution device is the subscriber node in the multicast group.

[0056] Optionally, in this embodiment, after the execution device is powered on, it first reads the locally configured second group identifier (Zone_ID=0001), determines the multicast group address to be joined according to the preset first mapping relationship, and then sends an IGMP Join message (i.e., the first request) to the local switch (i.e., the aforementioned communication device). The switch verifies whether the Zone_ID is valid and whether the device is authorized to join according to its ACL policy and mapping table. If the verification is successful, the switch updates the multicast forwarding table and sends an IGMP response (i.e., the first response) to confirm. After receiving the first response, the execution device determines that a multicast connection has been established, starts listening to the address, and can receive multicast messages from the probe device in the same multicast group to realize event processing.

[0057] In this embodiment, by using a preset mapping relationship between group identifiers and multicast group addresses, the execution device automatically completes multicast joining access authentication after power-on. Through verification of the communication device's response to the joining request, unauthorized devices are effectively prevented from accessing the multicast group, avoiding erroneous linkage between devices caused by broadcast storms or malicious injection, thus improving the system's security and manageability.

[0058] In an exemplary embodiment, parsing the first message to obtain the first event type and first group identifier of the first event included in the first message includes: performing a verification operation on the first message, wherein the verification operation includes at least one of the following: verifying whether the protocol header in the first message is in a preset format; verifying whether the fields in the first message match preset rules; if the first message includes a checksum field, comparing whether a first value calculated by the execution device using a target algorithm is consistent with a second value in the checksum field to determine the integrity of the first message, wherein the second value is a value calculated by the detection device using the target algorithm; if the verification of the first message is determined to be successful, parsing the first message to obtain the occurrence time of the first event; and if the occurrence time is within a preset time period, extracting the first event type and the group identifier from the first message.

[0059] Optionally, the verification operation in this embodiment refers to a series of local verification actions performed by the execution device after receiving the first message in order to determine whether the message is legal, complete, authentic, and timely. The purpose is to filter out inappropriate messages before performing the first processing action.

[0060] Optionally, in this embodiment, whether the protocol header is in a preset format refers to the execution device checking whether the network layer or application layer protocol header structure of the first message (such as the User Datagram Protocol (UDP) header or a custom message header) conforms to the system's predefined format requirements such as byte length, field order, and version number. For example, under normal circumstances, the message header is fixed at 12 bytes, with the first 4 bytes being 0x46495XXX and the 5th to 6th bytes being the version number 0x01. If the header structure is incorrect (such as the length being incorrect), it is directly discarded and not proceeded to subsequent parsing, thereby preventing illegal data packets sent by devices outside the system from interfering with normal event processing (such as hacker injection or interference from devices from other vendors).

[0061] Optionally, in this embodiment, whether a field matches a preset rule refers to whether the value range, enumerated value, and data type of each key field in the device verification message conform to the system's preset legal rules. For example, whether the event type (Event_Code) of the first event is a value from the preset enumerated values, whether the first group identifier (Zone_ID) is a 4-byte integer, whether the device identifier (Device_ID) of the probe device is a 12-byte ASCII code, and whether the occurrence time (Timestamp) of the first event is an 8-byte Unix timestamp, etc. It should be noted that the rules described here are merely examples; in actual use, they can be set according to actual needs. This embodiment does not impose any limitations.

[0062] Optionally, in this embodiment, the checksum field is a value calculated by the probe device using a target algorithm on the message body (the first message excluding the checksum) before sending the first message, and embedded in the first message. The target algorithm is a deterministic algorithm used to calculate the checksum, including but not limited to CRC16, Fletcher-16, simple summation, etc. The first value is the checksum recalculated by the execution device after receiving the first message. The second value is the checksum included in the first message, calculated and sent by the probe device. By comparing the first value and the second value, the execution device can determine the integrity of the first message. When the first value and the second value are equal, it indicates that the first message has not been tampered with and is complete and reliable. When the first value and the second value are not equal, it indicates that the first message may have been tampered with and is less reliable.

[0063] Optionally, the preset time period in this embodiment refers to a time window threshold stored locally by the execution device to determine whether an event is "valid and timely," and the unit is milliseconds or seconds. For example, the preset time period is when the event occurs within 1 second of the current time. Setting the preset time period effectively prevents the execution of invalid processing actions due to excessive network latency (such as a smoke alarm that occurred 5 minutes ago).

[0064] Optionally, in this embodiment, after the execution device receives the first message multicast by the detection device, it first checks whether the first message header conforms to the preset 12-byte format; secondly, verifies whether the event type (Event_Code) of the first event is a legal enumerated value such as 0x01 (fire), 0x02 (gas), etc.; subsequently, uses the CRC16 algorithm (i.e., the above target algorithm) to recalculate the checksum for the other data in the first message except the checksum, and compares it with the checksum field included in the first message. If they are inconsistent, it discards the message; finally, extracts the occurrence time (Timestamp) field of the first event, compares it with the local system time. If the time difference exceeds 1 s, it determines that the message is an expired message and does not process it; only when all verifications pass, it resolves the first event type and the first group identifier included in the first message for subsequent processing.

[0065] Through this embodiment, a multi-dimensional integrity verification mechanism (protocol format, field rules, checksum verification) is introduced before parsing the first message, and combined with time validity judgment, to ensure that only legal, complete, and real-time first messages can trigger the subsequent execution device to execute the first processing operation, effectively filtering false messages generated by network interference, signal crosstalk, device failures, or malicious attacks, and avoiding the execution of unnecessary processing actions.

[0066] In an exemplary embodiment, the above method further includes: receiving a control instruction sent by the target server, where the control instruction is an instruction generated by the target server based on the second message sent by the detection device and sent when it is monitored that the first event has not been processed within a preset time interval. The second message includes a message unicast to the target server when the detection device multicasts the first message, and the second message is used to request the target server to process the first event; responding to the control instruction to start the execution component included in the execution device; after determining that the execution component has completed starting, execute a second processing action through the execution component, where the second processing action includes an action to process the first event.

[0067] Optionally, the target server in this embodiment refers to a centralized monitoring and decision-making management node deployed in the cloud or local network, which does not participate in real-time linkage control and only sends control instructions for processing events when the execution device fails to complete an effective response. The target server can receive the second message unicast by the detection device and parse and save the second message.

[0068] Optionally, in this embodiment, the second message refers to a message that the probing device independently unicasts to the target server while sending the multicast first message. Its content is essentially the same as the first message, but its purpose is different. The second message is used to request the target server to record the data included in the message and monitor whether the first event is processed in a timely manner. The second message includes, but is not limited to: the event type (Event_Code) of the first event, the first group identifier (Zone_ID), the device identifier (Device_ID) of the probing device, the occurrence time (Timestamp) of the first event, and the event priority (Priority_Level) used to indicate the urgency of the first event.

[0069] Optionally, the preset time interval in this embodiment refers to the maximum waiting time threshold set by the target server to determine whether the execution device processes the event in a timely manner, in seconds or milliseconds (e.g., 5 seconds). This time is set based on a combination of network latency, device response time, and processing action time. For example, the detection device multicasts the first message to the execution device at T=0s. The execution device should complete the linkage (e.g., the curtain descends) within t≤5s. The target server receives the second message at T=0s and starts timing. If the target server still does not receive confirmation of "successful execution of the first processing action" at T=5.1s (e.g., the execution device returns the status, or the detection device is still sending similar messages), it is determined that the first event has not been processed in a timely manner. The target device then parses the second message and sends control commands.

[0070] Optionally, in this embodiment, the control command refers to the command actively issued by the target server to the execution device after detecting that the first event has not been processed within a preset time interval. This command is used to forcibly start the execution component and serves as a remedial measure when the execution device fails to automate. The control command explicitly specifies the identifier of the execution device and the execution action (e.g., start the roller shutter, turn on the sprinkler).

[0071] Optionally, the execution component in this embodiment is the smallest functional unit within the execution device used to complete physical or logical actions, including but not limited to relays, motor drivers, communication interfaces, and voice playback modules. Upon receiving a control command, the execution device first starts the component (e.g., power-on, wake-up, initialization) before executing the second processing action to ensure the component is in a ready state.

[0072] Optionally, in this embodiment, the second processing action refers to the event processing operation directly corresponding to the first event, executed by the execution device according to the control instructions issued by the target server after the execution component has started. The second processing action includes, but is not limited to, obtaining it by the target server by querying the linkage logic table stored locally on the execution device or by using the locally deployed model; this embodiment does not impose any limitations on this.

[0073] Optionally, the target server in this embodiment includes, but is not limited to, control instructions obtained from the second message in the following manner: first, performing a verification operation on the second message, wherein the verification operation includes at least one of the following: verifying whether the protocol header in the second message is in a preset format; verifying whether the fields in the second message match preset rules; if the second message includes a checksum field, comparing whether the first value calculated by the execution device using the target algorithm is consistent with the second value in the checksum field to determine the integrity of the second message, wherein the second value is the value calculated by the detection device using the target algorithm; if it is determined that the second message verification is successful and the occurrence time of the event included in the second message is within a preset time period, extracting the event type and group identifier from the second message; determining the second processing action corresponding to the event type based on the event type, determining the execution device that needs to perform the second processing action based on the group identifier, encapsulating the identifier of the execution device and the second execution action in a control instruction to start the execution component included in the execution device, and after determining that the execution component has been started, executing the second processing action through the execution component, wherein the second processing action includes the action of processing the event.

[0074] In this embodiment, when the execution device fails to perform the first processing action within a preset time interval for unknown reasons or the first processing action fails to be performed, the target server actively issues a control command to ensure that the first event can be processed in a timely manner even if the execution device fails or cannot process the first event in a timely manner.

[0075] In one exemplary embodiment, obtaining a first message multicast by a detection device for requesting processing of a first event includes: receiving a plurality of third messages multicast by the detection device; if the event types of each event included in the plurality of third messages include a second event type, determining that the detection device has malfunctioned, and determining the fault time of the detection device malfunction based on the occurrence time of the event of the second event type; if the event types of each event included in the plurality of third messages include the first event type, determining a first target message included in the plurality of third messages as the first message, wherein the occurrence time of the event of the first event type included in the first target message is earlier than the fault time.

[0076] Optionally, in this embodiment, the third message refers to an event message packet sent multiple times by the same detection device in a continuous or short period of time via multicast. The third message includes, but is not limited to: the event type (Event_Code), the group identifier (Zone_ID), the device identifier (Device_ID) of the detection device, the event occurrence time (Timestamp), and the event priority (Priority_Level) used to indicate the urgency of the event.

[0077] Optionally, the second event type in this embodiment refers to a fault event identifier actively issued by the detection device when its own hardware or software malfunctions, which indicates that the detection device no longer has the ability to accurately perceive the environment and collect data, and any data it outputs is unreliable.

[0078] Optionally, in this embodiment, the fault time refers to the timestamp when the detection device sends the first message including the second event type, i.e., the precise moment when the system determines that the detection device has malfunctioned. In actual use, the fault time can be the occurrence time of the event included in the third message or the occurrence time of the event included in the third message minus a preset duration, wherein the preset duration is determined based on the statistical analysis of historical detection device fault records.

[0079] Optionally, the first event type in this embodiment refers to other event types besides the event type indicating a malfunction of the detection device, including but not limited to event types such as fire and gas leak.

[0080] Optionally, in this embodiment, the first target message refers to a message sent before the detection device malfunctions.

[0081] The following is a specific example illustrating the method provided in this embodiment: A smoke detector sends a first message at T=0s, where the event type included in the first message is a fire event; a second message is sent at T=1.2s, where the event type included in the second message indicates that the smoke detector has malfunctioned; a third message is sent at T=1.5s, where the event type included in the third message is a fire event; the executing device determines the fault time of the smoke detector malfunction as T=1.2s based on the second message, and then determines that the occurrence time of the event included in the first message is earlier than the fault time, so the first message is determined as the first message (at this time, the first message is the aforementioned first target message), while the occurrence time of the event included in the third message is later than the fault time, so the third message is filtered out.

[0082] This embodiment utilizes continuous monitoring of multiple multicast messages from the detection device and identification of whether they include fault event types to automatically determine if the detection device is in a fault state. Based on the fault occurrence time, it filters out false alarm messages sent by the device after the fault, accepting only the third message sent before the fault. This mechanism avoids erroneous execution of processing actions caused by single-point device failure and improves the system's anti-interference capability under complex conditions such as equipment aging and environmental interference.

[0083] In one exemplary embodiment, after receiving the plurality of third messages multicast by the aforementioned detection device, the method further includes: if the event type of each event included in the plurality of third messages does not include the aforementioned second event type, then all of the plurality of third messages are determined to be the aforementioned first message.

[0084] Optionally, the third message and the second event type in this embodiment have been described above and will not be repeated here; please refer to the above description. In actual use, if the second event type is not included in the event types of each event included in multiple third messages, it indicates that the detection device has malfunctioned and can operate normally. Therefore, all third messages sent by the detection device are valid and should be regarded as first messages.

[0085] In practical use, when a detection device continuously sends multiple third messages, and none of these messages contain any second event type, the system will assume that the detection device is in normal operating condition. If multiple messages contain the same first event type (e.g., three consecutive reports all contain the event type "fire"), the execution device will perform event statistics: if multiple messages containing the same event type are received from the same device within a preset time window (e.g., 5 seconds), and the execution device and the detection device are in the same multicast group, the execution device will perform the first processing action; if the messages contain different types of first events (e.g., one is a fire type and the other indicates that the server in the computer room is overheating), the execution device will process them according to their priority, ensuring that events with higher priority are processed first.

[0086] In one exemplary embodiment, obtaining a first message multicast by a detection device for requesting processing of a first event further includes: receiving messages multicast by multiple detection devices to obtain multiple fourth messages; wherein the event type of each event included in the multiple fourth messages includes the first event type, and a second target message included in the multiple fourth messages for requesting processing of an event of the first event type is multicast by a target detection device, the second target message is determined as the first message, wherein the target detection device is a normally operating device.

[0087] Optionally, the fourth message in this embodiment is an event message packet sent by the probe device via multicast. The fourth message includes, but is not limited to: the event type (Event_Code), the group identifier (Zone_ID), the device identifier (Device_ID) of the probe device, the event occurrence time (Timestamp), and the event priority (Priority_Level) used to indicate the urgency of the event.

[0088] Optionally, the first event type in this embodiment refers to other event types besides the event type indicating a malfunction of the detection device, including but not limited to event types such as fire and gas leak.

[0089] Optionally, in this embodiment, the second target message is a message issued by a detection device that is determined to be operating normally, which is the first event type among multiple fourth messages.

[0090] The following is a specific example to illustrate the method provided in this embodiment: Within a multicast group, there are three detection devices D101, D102, and D103. At T=0.1s, D101 multicasts a fourth message with an event type of fire. At T=0.3s, D102 detects real smoke and multicasts a fourth message with an event type of fire. At T=0.4s, D103 multicasts a fourth message with an event type of fire. After receiving the three fourth messages, the executing device determines... They all include the first event type, and based on the messages received in the past, it was determined that D101 and D102 have no recent fault records. D103 multicast a message indicating a device fault at T=0.2s, and no message indicating that D103 has recovered was received from the target server. Therefore, D103 was determined to be a faulty device. Finally, the messages sent by D101 and D102 were determined to be the second target messages, and the fault of D103 was reported again to the corresponding maintenance personnel to prompt timely repair of D103.

[0091] This embodiment identifies a second target message from a normally functioning detection device among multiple similar events by receiving multicast messages from multiple detection devices. This second target message is then used as the first message to determine the first processing action to be performed by the subsequent execution device. This avoids erroneous execution of processing actions caused by device failure and improves the system's anti-interference capability under complex conditions such as device aging and environmental interference.

[0092] The following is a specific example to illustrate the above method: Five intelligent fire detection terminals (including smoke detectors, heat detectors, and manual alarm buttons) were deployed on the basement floor of a high-rise commercial complex. The corresponding device identifiers are G1, G2, G3, G4, and G5. Within a time interval of T=0.0s~0.8s, each of these five detection devices multicast a fourth message. Specifically, Figure 4 This is a flowchart illustrating a method for handling fire alarm events according to an embodiment of this application, as shown below. Figure 4 As shown, the process of executing this method by the device may include the following steps:

[0093] Step S402: Receive the fourth message from the multicast of five detection devices, and obtain five fourth messages;

[0094] Step S404: Based on the above five fourth messages and the historical messages stored in the execution device, determine the operating status of each detection device: G1, G2, and G3 have no historical anomalies, communication is stable, and the event type included in the fourth message they sent this time is not a fault type (i.e., the above second event type), so they are marked as normally operating devices. G4 previously sent an event including a fault type and did not receive a message instructing G4 to return to normal, so G4 is marked as a faulty device. G5 has no historical anomalies, but the event type included in the fourth message sent by G5 this time is a fault type, so G5 is marked as a faulty device.

[0095] Step S406: The fourth message sent by the normally operating device is identified as the first message, resulting in three first messages;

[0096] Step S408: Perform a verification operation on each first message to filter out first messages with incorrect format or incomplete format. The verification operation includes at least one of the following: verifying whether the protocol header in the first message is in a preset format; verifying whether the fields in the first message match preset rules; and, if the first message includes a checksum field, comparing whether the first value calculated by the execution device using the target algorithm is consistent with the second value in the checksum field to determine the integrity of the first message. The second value is the value calculated by the detection device using the target algorithm.

[0097] Step S410: Parse the three first messages that have passed the verification respectively to obtain the group identifier included in each first message;

[0098] Step S412: Based on the group identifier, determine whether each of the above-mentioned execution devices and detection devices are located in the same multicast group, and retain the first message of the detection device multicasting in the same multicast group as the execution device, and obtain three fifth messages;

[0099] Step S414: parse the three fifth messages respectively to obtain the event type of the events included in each fifth message;

[0100] Step S416: If the event type is determined to be the target type, query the event processing table stored locally on the execution device based on the device identifier included in the fifth message to determine the first processing action to be performed; wherein, the event processing table includes processing actions for the target type event under different conditions, for example: when only one detection device sends a message containing the target type event, the first-level processing action is triggered, which includes activating the audible and visual alarm in this area; when two detection devices send messages containing the target type event, the second-level processing action is triggered, which includes driving the fireproof roller shutter to close, the smoke exhaust valve to open, or the sprinkler device to start;

[0101] Step S418: Perform the first processing action by executing the device.

[0102] Through this optional example, in practical use, when multiple detection devices multicast multiple fourth messages, the fourth message sent by a detection device with a normal operating status is identified as the first message, and each first message is verified. Based on the first message, the first processing action to be executed by the execution device is further determined. The entire process is executed locally by the execution device, without relying on a central server, improving system reliability and the timeliness of event processing. This solves the problem in related technologies where events cannot be processed in a timely manner when the central server is abnormal, achieving the technical effect of improving event processing efficiency by enabling the execution device to process events promptly without relying on a central server.

[0103] According to another aspect of the embodiments of this application, a message multicast method is also provided. Taking the event processing method of the embodiments of this application executed by the detection device 102 as an example, Figure 5 This is a flowchart illustrating a message multicast method according to an embodiment of this application, as shown below. Figure 5 As shown, the process of this method may include the following steps:

[0104] Step S502: Multicast a first message, wherein the first message is used to request the execution device to process a first event, the first message includes a first event type and a first group identifier of the first event, the first group identifier is used to identify the multicast group in which the detection device is located, the execution device is used to perform a first processing action when it is determined that the first event type is a target type, and the execution device and the detection device are located in the same multicast group based on the first group identifier, the execution device has the ability to process the target type event, and the first processing action includes the action of processing the first event.

[0105] Figure 3 This is a flowchart illustrating a method for handling fire alarm events in related technologies, such as... Figure 3 As shown, in related technologies, the detection device 302 must first unicast the alarm information to the central server 304, which then performs event type identification, cross-regional correlation analysis, and linkage strategy matching before finally issuing instructions to the execution device 306. This process is inevitably interrupted when the central server malfunctions, leading to delays or even complete failure in event processing. In the method provided in this embodiment, the detection device no longer searches for the central server but instead multicasts the first message to the execution device. Upon receiving this message, the execution device does not need to communicate with any remote server; it only needs to locally parse the first message to obtain the first event type and the first group identifier. It can then locally determine that the first event type is the target type (e.g., fire, manual alarm). If the detection device and the execution device are located in the same area, the first processing action (e.g., activating the audible and visual alarm, closing the fireproof roller shutter) is immediately executed.

[0106] Optionally, the message multicast method in this embodiment can be applied to various scenarios requiring low-latency, decentralized, distributed intelligent control, including but not limited to applications in fire alarm systems, intelligent building automation management, industrial automation management, and rail transit tunnel management. For example, in a fire compartment of a high-rise residential building, when a smoke detector (i.e., the aforementioned detection device) detects a fire (i.e., the aforementioned first event) and multicasts the first message, subsequent execution devices within the same group can autonomously trigger execution actions through fire shutter controllers, smoke exhaust valve drivers, and audible and visual alarms without intervention from a central server. In a factory production line, when a vibration sensor (i.e., the aforementioned detection device) detects an equipment malfunction and multicasts an overheating event (i.e., the aforementioned first event), subsequent execution devices within the same group can immediately respond to the overheating event through nearby emergency stop relays and ventilation systems without intervention from a central server.

[0107] Optionally, the detection device in this embodiment is an intelligent terminal deployed in the physical environment to sense specific events and possessing network communication capabilities. It can locally determine the collected physical signals (such as smoke concentration, temperature, manual triggering, etc.), and when preset conditions are met, actively construct and multicast a first message including the event type and group identifier, and store the collected data. The detection device includes, but is not limited to, smoke detectors, heat detectors, manual fire alarm buttons, gas detectors, flame detectors, water immersion sensors, or intelligent cameras with edge intelligent analysis capabilities. It should be noted that the above is merely an illustrative example, and those skilled in the art can flexibly configure the detection device according to the actual application scenario requirements.

[0108] Optionally, after collecting data, the detection device in this embodiment will first determine whether the collected data meets preset conditions. If the preset conditions are met, it will determine that a first event has occurred and send a first message. For example, in a fire alarm scenario, the preset condition could be that the smoke concentration exceeds a threshold, and the duration of the smoke concentration exceeding the threshold is not less than 5 seconds. It should be noted that the above is only an illustrative example, and those skilled in the art can flexibly design corresponding preset conditions according to the actual application scenario requirements.

[0109] Optionally, in this embodiment, the first message refers to a structured network data packet sent by the probe device via multicast. The first message includes, but is not limited to: the event type (Event_Code) of the first event, the first group identifier (Zone_ID), the device identifier (Device_ID) of the probe device, the occurrence time (Timestamp) of the first event, and the event priority (Priority_Level) used to indicate the urgency of the first event.

[0110] Optionally, the first event type in this embodiment refers to the event category with predefined semantics identified by the detection device after local judgment, which is used to distinguish triggering events of different natures (such as fire, overheating, leakage, malfunction, etc.). The first event type includes, but is not limited to, those represented by preset enumeration identifiers (such as "Fire" indicating a fire, "Overheat" indicating overheating of other monitored devices, and "GasLeak" indicating a leak of harmful gas in the area where the detection device is located).

[0111] Optionally, in this embodiment, the first group identifier is used to identify the multicast group to which the detection device belongs. Ideally, the detection device should only join one multicast group. The first group identifier includes, but is not limited to, configurations based on physical or logical boundaries such as building fire compartments, production line units, and room numbers. The first group identifier includes, but is not limited to, allocations made through factory settings, distribution from the target server, or network protocols.

[0112] Optionally, in this embodiment, the target type refers to a specific event type predefined in the linkage logic table stored locally by the execution device, which can trigger a processing action. The execution device only responds to events matching the "target type" and ignores events of non-target type, thereby achieving selective and conditional response. For example, if "target type = Fire" is defined in the linkage logic table stored locally by the execution device, the execution device will only respond to and process the "Fire" event. It should be noted that in actual use, an execution device can process multiple types of events (e.g., events with event types "Fire", "GasLeak", and "Overheat" can all be processed). When the execution device can process multiple types of events, it will determine the execution order of various different processing actions based on event priority (e.g., processing actions for events with higher priority are executed first). In addition, the linkage logic table may also store composite conditions, such as the execution device only executing the first processing action when the target type = "Fire" and the number of devices sending messages is ≥2. The first processing action includes, but is not limited to, obtaining it by querying the linkage logic table stored locally by the execution device or using a locally deployed model; this embodiment does not impose any limitations on this.

[0113] Optionally, in this embodiment, the first processing action refers to the action taken by the execution device to process the first event under the conditions that "the event type is the target type" and "multicast group matching" is met. This action can be a physical operation or a communication command. The first processing action includes, but is not limited to, activating an audible and visual alarm, closing a fireproof roller shutter, opening a smoke exhaust valve, cutting off non-fire-fighting power, sending a text message notification, or displaying an application pop-up window.

[0114] Optionally, the execution device in this embodiment is used to listen to messages sent by the detection devices in its own group and autonomously trigger actions to achieve distributed control without the reliance on a central server. The execution device includes, but is not limited to, audible and visual alarms, fireproof roller shutter controllers, smoke exhaust valve drivers, fire pump start modules, non-fire power cut-off devices, elevator emergency landing controllers, electromagnetic locks, gas extinguishing start devices, air conditioning fresh air system controllers, or industrial production line emergency stop relays.

[0115] In this embodiment, the detection device has the capability to send multicast messages, not just unicast messages. It can then send a first message, including a first event type and a first group identifier, to the execution device via multicast. Upon receiving the first message, the execution device can parse it to obtain the first event type and first group identifier without communicating with any remote server. It can then locally perform a dual check: the execution device and the detection device are in the same multicast group, and the first event type is the target type. If both conditions are met, the execution device performs a first processing action to process the first event. The entire process is executed locally by the execution device. The detection device's multicast message capability ensures that subsequent event processing does not rely on any central server. Therefore, it solves the problem in related technologies where events cannot be processed promptly in the event of a central server malfunction. This achieves the technical effect of improving event processing efficiency by enabling the execution device to process events promptly without relying on a central server.

[0116] In one exemplary embodiment, prior to the multicast first message, the method further includes: determining a second multicast packet address corresponding to the first packet identifier from a second mapping relationship based on a pre-allocated first packet identifier, wherein the second mapping relationship is used to indicate the mapping relationship between the packet identifier and the multicast packet address, and the first packet identifier is used to identify the second multicast packet corresponding to the second multicast packet address; sending a second request to a communication device to request that the probe device be added to the second multicast packet; receiving a second response from the communication device in response to the second request; and determining that the probe device has established a multicast connection with the execution device if the second response indicates that the communication device allows the probe device to join the second multicast packet, wherein the transmission of multicast messages is permitted among multiple devices under the multicast connection.

[0117] Optionally, in this embodiment, the first group identifier refers to a unique identifier pre-assigned to a logical area (such as "East side of the 1st floor" or "Production line in area A") during the system deployment phase. It is used to logically delineate control boundaries and is a semantic name of the area, not a network address. The first group identifier includes, but is not limited to, allocation through factory settings, distribution by the target server, or network protocols.

[0118] Optionally, the second mapping relationship in this embodiment refers to a configuration table or rule set that is pre-set or dynamically maintained in the execution device to establish a unique mapping relationship between the group identifier (such as Zone_ID) and the corresponding IP multicast address (such as 239.XXX.1.1), and to convert the semantic zone name into a multicast group address that can be addressed by the network layer.

[0119] Optionally, in this embodiment, the communication device refers to a network node responsible for forwarding, managing, or controlling multicast membership relationships throughout the system. It possesses multicast management protocol processing capabilities, can receive and respond to multicast join requests from various devices, and decides whether to allow them to join the target multicast group. Communication devices include, but are not limited to, switches, Layer 3 routers, and smart gateways.

[0120] Optionally, in this embodiment, the second request is a network protocol message sent by the detection device to the communication device after power-on or configuration, which is used to request to join a specified multicast group. The second request includes the MAC address or IP address of the detection device and the second multicast group.

[0121] Optionally, the second response in this embodiment is an acknowledgment or rejection message (such as an IGMP response or ACL allow / deny) returned by the communication device after receiving the second request, based on the device permission policy.

[0122] Optionally, in this embodiment, the multicast connection refers to a logical communication channel established between the execution device and the probe device based on IP multicast communication after the communication device completes multicast member management. This channel allows all members within the same multicast group to send multicast messages bidirectionally or unidirectionally without requiring a point-to-point connection. In a multicast group, the probe device is the publisher node in the multicast group, and the execution device is the subscriber node in the multicast group.

[0123] Optionally, in this embodiment, after the probe device powers on, it first reads the locally configured first group identifier (Zone_ID=0002), determines the multicast group address to be joined according to the preset second mapping relationship, and then sends an IGMP Join message (i.e., the second request) to the local switch (i.e., the aforementioned communication device). The switch verifies whether the Zone_ID is valid and whether the device is authorized to join according to its ACL policy and mapping table. If the verification is successful, the switch updates the multicast forwarding table and sends an IGMP response (i.e., the second response) to confirm. After receiving the second response, the probe device determines that a multicast connection has been established and can multicast a message to the execution device of the same multicast group to request event processing.

[0124] In this embodiment, by using a preset mapping relationship between group identifiers and multicast group addresses, the detection device automatically completes multicast joining access authentication after power-on. Through verification of the communication device's response to the joining request, unauthorized devices are effectively prevented from accessing the multicast group, avoiding erroneous linkage between devices caused by broadcast storms or malicious injection, thus improving the system's security and manageability.

[0125] The following concrete example illustrates the above method: Multiple intelligent fire detection devices (i.e., the aforementioned detection devices) and execution devices are deployed in a factory. This area is divided into four independent fire protection zones (Zone_ID: 0001 to 0004), each group corresponding to a unique IPv4 multicast address (e.g., 239.XXX.1.1 to 239.XXX.1.4). Accurate forwarding of multicast traffic is achieved through a Layer 2 switch supporting IGMP Snooping. Specifically, Figure 6 This is a flowchart illustrating a method for handling fire events within an event handling system according to an embodiment of this application. The connection relationships between detection devices, execution devices, and communication devices in a certain area of ​​the factory are as follows: Figure 1 As shown, the execution device, communication device, and detection device are connected in sequence. The communication device is used to establish a multicast connection between the execution device and the detection device. Multiple devices under the multicast connection are allowed to transmit multicast messages, such as... Figure 6 As shown, the interaction process between the target server and the detection devices, execution devices, and communication devices in a certain area may include the following steps:

[0126] In step S602, the executing device (such as an audible and visual alarm, a fireproof rolling shutter control module, or a smoke exhaust valve driver) sends a first request to the communication device to request that the executing device be added to the corresponding multicast group.

[0127] In step S604, the detection device (such as a smoke detector, a heat detector, or a manual alarm button) sends a second request to the communication device to request that the detection device be added to the corresponding multicast group.

[0128] Step S606: The communication device sends a first response to the first request;

[0129] Step S608: The communication device sends a second response to the second request;

[0130] Step S610: If the first response indicates that the communication device allows the execution device to join the first multicast packet, it is determined that the execution device has established a multicast connection with the detection device.

[0131] Step S612: If the second response indicates that the communication device allows the probe device to join the first multicast packet, it is determined that the execution device has established a multicast connection with the probe device.

[0132] Step S614: The detection device continuously collects data. When the collected data meets the preset conditions, it determines that the first event has occurred. The first message is multicast to the execution device through the multicast module. For example, when a smoke detector in Zone_ID=0001 detects that the smoke concentration continuously exceeds the threshold within 5 seconds, its internal event determination module determines it as a real fire event.

[0133] Step S616: The detection device continuously collects data. When the collected data meets the preset conditions, it determines that the first event has occurred. The second message is unicast to the target server through the unicast module to instruct the target server to continuously monitor whether the event is processed.

[0134] Step S618: The execution device performs a verification operation on the first message, and if it is determined that the first message passes verification and the occurrence time of the event included in the first message is within a preset time period, the event type and group identifier are extracted from the first message. The verification operation includes at least one of the following: verifying whether the protocol header in the first message is in a preset format; verifying whether the fields in the first message match preset rules; if the first message includes a checksum field, comparing whether the first value calculated by the execution device using the target algorithm is consistent with the second value in the checksum field to determine the integrity of the first message, wherein the second value is the value calculated by the detection device using the target algorithm.

[0135] In step S620, when the execution device determines that the event type is the target type and determines that the execution device and the detection device are in the same multicast group based on the group identifier, the execution device performs a first processing action. The execution device has the ability to process events of the target type, and the first processing action includes the action of processing the event.

[0136] Step S622: If the target server detects that an event has not been processed within a preset time interval, it sends a control command to the execution device.

[0137] Step S624: Execute the device response control command to start the execution component included in the execution device, and after determining that the execution component has been started, execute the second processing action through the execution component, wherein the second processing action includes the action of processing the first event mentioned above.

[0138] The target server includes, but is not limited to, control instructions obtained from the second message through the following methods: first, performing a verification operation on the second message, wherein the verification operation includes at least one of the following: verifying whether the protocol header in the second message is in a preset format; verifying whether the fields in the second message match preset rules; if the second message includes a checksum field, comparing whether the first value calculated by the execution device using the target algorithm is consistent with the second value in the checksum field to determine the integrity of the second message, wherein the second value is the value calculated by the detection device using the target algorithm; if the second message verification is successful and the occurrence time of the event included in the second message is determined to be within a preset time period, extracting the event type and group identifier from the second message; determining the second processing action corresponding to the event type based on the event type, determining the execution device that needs to perform the second processing action based on the group identifier, encapsulating the identifier of the execution device and the second execution action in a control instruction to start the execution component included in the execution device, and after determining that the execution component has been started, executing the second processing action through the execution component, wherein the second processing action includes the action of processing the event.

[0139] It should be noted that the order of steps S602 and S604 in this embodiment is not fixed; that is, step S604 can be executed before step S602, or steps S602 and S604 can be executed simultaneously. Similarly, the order of steps S606 and S608 in this embodiment is not fixed; that is, step S608 can be executed before step S606, or steps S606 and S608 can be executed simultaneously. Steps S622 and S624 in this embodiment are not mandatory steps; that is, steps S622 and S624 will only be executed if the target server detects that an event has not been processed within a preset time interval. In actual use, the execution device will continuously monitor the connection status with the target server. If the connection is interrupted due to network failure or server downtime, all logic dependent on the target server (such as remote reset and cloud log synchronization) will be automatically shut down, and a message indicating a target server failure will be pushed to the corresponding maintenance personnel immediately to ensure that the target server can be repaired in a timely manner. Once the network between the execution device and the target server is restored and the target server comes back online, the execution device unicasts a local event processing summary to the target server (e.g., including the event time, event type, the identifier of the execution device, and the corresponding processing action) for the target server to perform log alignment.

[0140] In this optional example, steps S602-S612 involve the execution device and the detection device actively applying to join the same multicast group. Precise multicast member management is achieved by communication equipment (e.g., a switch), enabling automatic regional networking between devices with plug-and-play capability and no central configuration required, greatly simplifying the deployment process. This ensures that only verified messages are processed promptly, preventing erroneous execution of processing actions due to false alarms and network interference. Steps S622-S624, where the target server controls the execution device to process events, and steps S618-S620, where the execution device performs processing actions, form a dual-channel event processing mechanism. The execution device first performs processing actions to complete the timely processing of events. The target server serves as a backup solution; if the execution device fails to process events due to an anomaly (e.g., actuator failure), the target server can still forcibly wake up the execution component in the execution device to perform a second processing action. This achieves the effect of timely event processing by the execution device without relying on a central server, and also enables timely event processing by sending control commands from the target server when the execution device malfunctions.

[0141] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0142] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as read-only memory (ROM) / random access memory (RAM), magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0143] According to another aspect of the embodiments of this application, an execution device is also provided, which can be used to implement the event processing method provided in the above embodiments, and will not be repeated hereafter. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0144] Figure 7 This is a structural block diagram of an execution device according to an embodiment of this application, such as... Figure 7 As shown, the device includes:

[0145] The acquisition module 72 is used to acquire the first message multicast by the detection device, which requests processing of the first event;

[0146] The parsing module 74 is used to parse the first message to obtain the first event type and the first group identifier of the first event included in the first message, wherein the first group identifier is used to identify the multicast group to which the detection device is located;

[0147] The execution module 76 is configured to perform a first processing action through the execution device when the first event type is determined to be a target type and the execution device and the detection device are located in the same multicast group based on the first group identifier. The execution device has the capability to process events of the target type, and the first processing action includes processing the first event.

[0148] It should be noted that the acquisition module 72 in this embodiment can be used to execute the above step S202, the parsing module 74 in this embodiment can be used to execute the above step S204, and the execution module 76 in this embodiment can be used to execute the above step S206.

[0149] According to the embodiments provided in this application, when the execution device receives the first multicast message from the probe device, it can parse the first message itself to obtain the first event type and the first group identifier without communicating with any remote server. It can then locally perform a dual judgment that "the execution device and the probe device are in the same multicast group, and the first event type is the target type." If both conditions are met, the execution device performs a first processing action to process the first event. The entire process is executed entirely locally by the execution device, without relying on any central server. Therefore, it solves the problem in related technologies where events cannot be processed in a timely manner when the central server is abnormal, achieving the technical effect of improving event processing efficiency by enabling the execution device to process events promptly without relying on a central server.

[0150] In an exemplary embodiment, the execution module 76 is further configured to, before determining the first message sent by the probe device requesting processing of the first event, determine, based on a pre-allocated second packet identifier, a first multicast packet address corresponding to the second packet identifier from a first mapping relationship, wherein the first mapping relationship is used to indicate the mapping relationship between the packet identifier and the multicast packet address, and the second packet identifier is also used to identify the first multicast packet corresponding to the first multicast packet address; send a first request to the communication device to request that the execution device be added to the first multicast packet; receive a first response sent by the communication device in response to the first request; and, if the first response is used to indicate that the communication device allows the execution device to join the first multicast packet, determine that the execution device has established a multicast connection with the probe device, wherein the transmission of multicast messages is allowed among multiple devices under the multicast connection.

[0151] In an exemplary embodiment, the parsing module 74 is further configured to parse the first message in the following manner to obtain the first event type and the first group identifier of the first event included in the first message: performing a verification operation on the first message, wherein the verification operation includes at least one of the following: verifying whether the protocol header in the first message is in a preset format; verifying whether the fields in the first message match a preset rule; if the first message includes a checksum field, comparing whether the first value calculated by the execution device using the target algorithm is consistent with the second value in the checksum field to determine the integrity of the first message, wherein the second value is the value calculated by the detection device using the target algorithm; if the verification of the first message is determined to be successful, parsing the first message to obtain the occurrence time of the first event; if the occurrence time is within a preset time period, extracting the first event type and the group identifier from the first message.

[0152] In an exemplary embodiment, the apparatus is further configured to receive a control instruction sent by a target server, wherein the control instruction is generated by the target server based on a second message sent by the detection device and sent when the first event is detected to have not been processed within a preset time interval, the second message including a message unicast to the target server when the detection device multicasts the first message, the second message being used to request the target server to process the first event; respond to the control instruction to start the execution component included in the execution device; and after determining that the execution component has been started, perform a second processing action through the execution component, wherein the second processing action includes the action of processing the first event.

[0153] In an exemplary embodiment, the acquisition module 72 is further configured to acquire a first message from the detection device multicast for requesting processing of a first event by: receiving a plurality of third messages from the detection device multicast; if the event types of each event included in the plurality of third messages include a second event type, determining that the detection device has malfunctioned, and determining the fault time of the detection device based on the occurrence time of the event of the second event type; if the event types of each event included in the plurality of third messages include the first event type, determining a first target message included in the plurality of third messages as the first message, wherein the occurrence time of the event of the first event type included in the first target message is earlier than the fault time.

[0154] In an exemplary embodiment, the acquisition module 72 is further configured to, after receiving the plurality of third messages multicast by the detection device, determine all of the plurality of third messages as the first message if the event type of each event included in the plurality of third messages does not include the second event type.

[0155] In an exemplary embodiment, the acquisition module 72 is further configured to acquire a first message for requesting processing of a first event via multicast by the detection devices in the following manner: receiving messages multicast by multiple detection devices respectively to obtain multiple fourth messages; in the case where the event type of each event included in the multiple fourth messages includes the first event type, and the second target message for requesting processing of the first event type included in the multiple fourth messages is multicast by the target detection devices, the second target message is determined as the first message, wherein the target detection devices are normally operating devices.

[0156] According to another aspect of the embodiments of this application, a detection device is also provided, which can be used to implement the message multicast method provided in the above embodiments, and will not be repeated hereafter. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0157] Figure 8 This is a structural block diagram of a detection device according to an embodiment of this application, such as... Figure 8As shown, the device includes: a multicast module 82 for multicasting a first message, wherein the first message is used to request an execution device to process a first event, the first message includes a first event type and a first group identifier of the first event, the first group identifier is used to identify the multicast group in which the detection device is located, the execution device is used to perform a first processing action when it is determined that the first event type is a target type, and the execution device and the detection device are located in the same multicast group based on the first group identifier, the execution device has the ability to process the target type event, and the first processing action includes the action of processing the first event.

[0158] It should be noted that the multicast module 82 in this embodiment can be used to perform the above step S502.

[0159] In an exemplary embodiment, the multicast module 82 is further configured to, before multicasting the first message, determine the second multicast packet address corresponding to the first packet identifier from a second mapping relationship based on a pre-allocated first packet identifier, wherein the second mapping relationship is used to indicate the mapping relationship between the packet identifier and the multicast packet address, and the first packet identifier is used to identify the second multicast packet corresponding to the second multicast packet address; send a second request to the communication device to request that the probe device be added to the second multicast packet; receive a second response sent by the communication device in response to the second request; and, if the second response indicates that the communication device allows the probe device to join the second multicast packet, determine that the probe device has established a multicast connection with the execution device, wherein the transmission of multicast messages is allowed among multiple devices under the multicast connection.

[0160] According to another aspect of the embodiments of this application, an event processing system is also provided. Figure 1 This is a structural block diagram of an event handling system according to an embodiment of this application, such as... Figure 1 As shown, the system includes: an execution device 104 as provided in the above embodiment, a detection device 102 as provided in the above embodiment, and a communication device 106, wherein the execution device 104, the communication device 106 and the detection device 102 are connected in sequence, and the communication device 106 is used to establish a multicast connection between the execution device 104 and the detection device 102, and multiple devices under the multicast connection are allowed to transmit multicast messages.

[0161] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0162] According to another aspect of the embodiments of this application, a computer-readable storage medium is provided, the computer-readable storage medium including a stored program, wherein the program executes the steps in any of the above method embodiments when it is run.

[0163] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, ROMs, RAMs, portable hard drives, magnetic disks, or optical disks.

[0164] According to another aspect of the embodiments of this application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor is configured to perform the steps of any of the method embodiments described above via the computer program. In an exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0165] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0166] According to another aspect of the embodiments of this application, a computer program product is also provided, comprising a computer program / instructions containing program code for performing the methods shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via communication section 1009, and / or installed from removable medium 1011. When the computer program is executed by central processing unit 1001, it performs various functions provided in the embodiments of this application. The sequence numbers of the embodiments of this application above are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0167] Figure 9 This is a computer system architecture block diagram of an electronic device according to an embodiment of this application. For example... Figure 9 As shown, the computer system includes a Central Processing Unit (CPU) 901, which can determine the data stored in ROM (corresponding to...). Figure 9 The program is stored in the read-only memory 902 or loaded from the storage section 908 into the RAM (corresponding to the read-only memory 902). Figure 9The system executes various appropriate actions and processes by storing programs in the random access memory (RAM) 903. The RAM 903 also stores various programs and data required for system operation. The central processing unit 901, the read-only memory 902, and the RAM 903 are interconnected via a bus 904. An input / output (I / O) interface 905 is also connected to the bus 904.

[0168] The following components are connected to the I / O interface (corresponding to...) Figure 9 The input / output interface 905 includes an input section 906 such as a keyboard and mouse; an output section 907 including devices such as a cathode ray tube (CRT), a liquid crystal display (LCD), and speakers; a storage section 908 including a hard disk; and a communication section 909 including network interface cards such as LAN cards and modems. The communication section 909 performs communication processing via a network such as the Internet. A drive 910 is also connected to the input / output interface 905 as needed. A removable medium 911, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 910 as needed so that computer programs read from it can be installed into the storage section 908 as needed.

[0169] Specifically, according to embodiments of this application, the processes described in the various method flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 909, and / or installed from removable medium 911. When the computer program is executed by central processing unit 901, it performs various functions defined in the system of this application.

[0170] It should be noted that, Figure 9 The computer system of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0171] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those described herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0172] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. An event handling method, characterized in that, include: Obtain the first message from the detection device multicast, which requests processing of the first event; Parse the first message to obtain the first event type and the first group identifier of the first event included in the first message, wherein the first group identifier is used to identify the multicast group to which the detection device belongs; If the first event type is determined to be a target type, and the execution device and the detection device are located in the same multicast group based on the first group identifier, the execution device performs a first processing action, wherein the execution device has the capability to process events of the target type, and the first processing action includes the action of processing the first event.

2. The method according to claim 1, characterized in that, Before determining the first message multicast by the detection device requesting processing of the first event, the method further includes: Based on the pre-allocated second packet identifier, the first multicast packet address corresponding to the second packet identifier is determined from the first mapping relationship, wherein the first mapping relationship is used to indicate the mapping relationship between the packet identifier and the multicast packet address, and the second packet identifier is also used to identify the first multicast packet corresponding to the first multicast packet address; Send a first request to the communication device to request that the execution device be added to the first multicast group; Receive a first response to the first request sent by the communication device; When the first response is used to instruct the communication device to allow the execution device to join the first multicast group, it is determined that the execution device has established a multicast connection with the probe device, wherein the transmission of multicast messages is allowed among multiple devices under the multicast connection.

3. The method according to claim 1, characterized in that, Parsing the first message yields the first event type and first group identifier of the first event included in the first message, including: A verification operation is performed on the first message, wherein the verification operation includes at least one of the following: verifying whether the protocol header in the first message is in a preset format; verifying whether the fields in the first message match a preset rule; and, if the first message includes a checksum field, comparing whether a first value calculated by the execution device using a target algorithm is consistent with a second value in the checksum field to determine the integrity of the first message, wherein the second value is a value calculated by the detection device using the target algorithm. If the first message verification is successful, the first message is parsed to obtain the occurrence time of the first event; If the occurrence time falls within a preset time period, the first event type and the group identifier are extracted from the first message.

4. The method according to claim 1, characterized in that, The method further includes: The system receives a control command sent by a target server. The control command is generated by the target server based on a second message sent by the detection device and sent when the first event is detected to have not been processed within a preset time interval. The second message includes a message unicast to the target server when the detection device multicasts the first message. The second message is used to request the target server to process the first event. In response to the control command, the execution components included in the execution device are activated; After determining that the execution component has completed startup, a second processing action is performed through the execution component, wherein the second processing action includes the action of processing the first event.

5. The method according to claim 1, characterized in that, Obtain the first message from the detection device multicast, requesting processing of the first event, including: Receive multiple third messages multicast by the detection device; If the event type of each event included in the plurality of third messages includes a second event type, it is determined that the detection device has malfunctioned, and the malfunction time of the detection device is determined based on the occurrence time of the event of the second event type. If the event type of each event included in the plurality of third messages includes the first event type, the first target message included in the plurality of third messages is determined as the first message, wherein the occurrence time of the event of the first event type included in the first target message is earlier than the fault time.

6. The method according to claim 5, characterized in that, After receiving multiple third messages multicast by the detection device, the method also includes: If the second event type is not included in the event types of the events included in the plurality of third messages, then all of the plurality of third messages are determined to be the first message.

7. The method according to claim 1, characterized in that, The acquisition of the first message multicast by the detection device for requesting processing of the first event also includes: Receive messages multicast from multiple detection devices to obtain multiple fourth messages; If the first event type is included in the event types of the various events included in the plurality of fourth messages, and the second target message included in the plurality of fourth messages for requesting processing of the event of the first event type is multicast by the target detection device, then the second target message is determined as the first message, wherein the target detection device is a normally operating device.

8. A message multicast method, characterized in that, include: A multicast first message, wherein the first message is used to request an execution device to process a first event, the first message includes a first event type and a first group identifier of the first event, the first group identifier is used to identify the multicast group in which the probe device is located, the execution device is used to perform a first processing action when it is determined that the first event type is a target type, and the execution device and the probe device are located in the same multicast group based on the first group identifier, the execution device has the ability to process events of the target type, and the first processing action includes the action of processing the first event.

9. The method according to claim 8, characterized in that, Prior to the first multicast message, the method further includes: Based on the pre-allocated first packet identifier, the second multicast packet address corresponding to the first packet identifier is determined from the second mapping relationship, wherein the second mapping relationship is used to indicate the mapping relationship between the packet identifier and the multicast packet address, and the first packet identifier is used to identify the second multicast packet corresponding to the second multicast packet address; Send a second request to the communication device to request that the detection device be added to the second multicast group; Receive a second response to the second request sent by the communication device; In the case where the second response instructs the communication device to allow the probe device to join the second multicast group, it is determined that the probe device has established a multicast connection with the execution device, wherein the transmission of multicast messages is permitted among multiple devices under the multicast connection.

10. An execution device, characterized in that, include: The acquisition module is used to acquire the first message sent by the detection device via multicast, which requests processing of the first event; The parsing module is used to parse the first message to obtain the first event type and the first group identifier of the first event included in the first message, wherein the first group identifier is used to identify the multicast group to which the detection device belongs; An execution module is configured to, when determining that the first event type is a target type and determining that the execution device and the detection device are located in the same multicast group based on the first group identifier, execute a first processing action through the execution device, wherein the execution device has the capability to process events of the target type, and the first processing action includes an action to process the first event.

11. A detection device, characterized in that, include: A multicast module is used to multicast a first message, wherein the first message is used to request an execution device to process a first event. The first message includes a first event type and a first group identifier for the first event. The first group identifier is used to identify the multicast group in which the probe device is located. The execution device is used to perform a first processing action when it is determined that the first event type is a target type and the execution device and the probe device are located in the same multicast group based on the first group identifier. The execution device has the ability to process events of the target type. The first processing action includes the action of processing the first event.

12. An event processing system, comprising the execution device as described in claim 10, the detection device as described in claim 11, and the communication device, wherein, The execution device, the communication device, and the detection device are connected in sequence. The communication device is used to establish a multicast connection between the execution device and the detection device, and multiple devices under the multicast connection are allowed to transmit multicast messages.

13. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 7, or the steps of the method according to any one of claims 8 to 9.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7, or the steps of the method according to any one of claims 8 to 9.

15. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7, or the steps of the method according to any one of claims 8 to 9.

Images