Event alarm reporting processing method for large-scale ONVIF equipment access

Abstract

The invention discloses an event alarm reporting processing method for large-scale ONVIF equipment access, and belongs to the field of security and protection video monitoring. Registering channel static information to the data sharing center after the ONVIF equipment is online; the ONVIF equipment access service sends an event subscription request carrying an event receiving service unified address and an equipment identification subscription code to the equipment; after the equipment triggers the event, stateless connection is initiated to the uniform address, and the event is dynamically forwarded to any event receiving service instance by the platform load balancer; and the event receiving service analyzes the event to obtain the channel identifier, queries the data sharing center to obtain complete channel information, and reports the information to the platform alarm center after integration. According to the invention, decoupling of event subscription and processing is realized, and through stateless service, unified port and centralized data management, the problems of poor reliability, many exposed ports, uneven load and complex capacity expansion under large-scale access are solved.

Description

A method for reporting and handling event alarms in large-scale ONVIF device access Technical Field

[0001] This invention belongs to the field of security video surveillance technology, specifically relating to an event alarm reporting and processing method for large-scale ONVIF device access. Background Technology

[0002] In the field of security video surveillance, ONVIF (Open Network Video Interface Forum) is a global open industry standards forum. Its core goal is to achieve interoperability of network video products (such as network cameras, NVRs, etc.) produced by different manufacturers by developing and promoting interface standards between network video devices. Currently, almost all security network cameras have the access function of this protocol.

[0003] As a functional platform for device access control in the security industry, video surveillance platforms support network cameras from different manufacturers to access the system via the ONVIF protocol. In the actual device event processing flow, the ONVIF device access service sends event subscription requests to the devices, then receives event messages reported by the devices, parses and processes them, and forwards them to the platform's alarm center. However, with the large-scale growth in the number of connected devices, the processing capacity of a single ONVIF device access service can no longer meet business needs. It is necessary to expand capacity by deploying access services through multiple instances, which leads to a simultaneous increase in the number of ONVIF device access services as the number of devices increases.

[0004] Since the transmission of ONVIF event data depends on the mode of the device actively connecting to the ONVIF access service, the access service needs to expose a port to receive device connections; the multi-instance deployment corresponding to large-scale device access will inevitably lead to a multiplication of the number of ports exposed by the system. In order to reduce network security risks, reduce exposed ports, and simultaneously achieve decoupling of ONVIF device access service (responsible for signaling interaction) and device (responsible for event reporting) and separation of signaling and alarm data, the industry urgently needs targeted technical solutions. However, the existing technical solutions for ONVIF device event reporting have obvious limitations and are difficult to adapt to large-scale device access scenarios: I. Existing technical solutions (1) Single instance deployment solution The ONVIF device access service runs as a single instance, actively establishes a connection with the ONVIF device, and exposes a fixed event port to receive event alarm messages reported by the device. The specific business process is as follows (see Figure 1 for a flowchart): 1. After the device goes online, the ONVIF device access service sends an event subscription request to the device. The subscription request contains the address and port information of the access service; 2. After the device triggers an event alarm (such as motion detection or occlusion alarm), it actively connects to the event port of the ONVIF device access service and sends an event message; 3. After receiving the event message, the ONVIF device access service parses the subscription code and channel token information in the message, obtains the corresponding device channel information, and then reports the alarm information to the platform alarm center.

[0005] This type of solution is only suitable for small-scale device access scenarios (such as fewer than 100 devices). Due to the limited hardware resources and concurrent processing capabilities of a single instance, it cannot support large-scale device access of tens of thousands or more.

[0006] (2) Multi-instance deployment scheme: In order to overcome the single-instance access capacity limit, the ONVIF device access service adopts a multi-instance parallel operation mode: each instance independently and actively connects to some ONVIF devices and exposes different event ports (for devices to distinguish the instances to be connected). Its business process is the same as the single-instance scheme, but an independent port needs to be configured for each instance. When the device comes online, it is assigned to a specific instance by the platform, and the subscription request carries the address and port of the instance.

[0007] However, while this solution increases access capacity, it does not solve the core bottleneck of the single-instance solution and adds to the deployment complexity.

[0008] II. Core Shortcomings of Existing Technologies Based on industry practice and technical analysis, the existing solutions have the following unavoidable problems, and no effective solutions have been proposed by the relevant technologies: (1) Poor reliability of event services and easy interruption In the existing solutions, there is a one-to-one stateful connection between the ONVIF device and the ONVIF device access service instance - the device can only report events to the access service instance that sent the subscription request. If the access service instance goes offline due to failure (such as server crash or network interruption), the device will not be able to establish a connection to send event messages, and can only wait for the device to come back online and receive subscription requests again before the event service can be restored. For example, if the platform deploys multiple ONVIF access service instances, each instance connects to several devices. If an instance is abnormal, all the devices bound to it will be unable to report events until the device restarts or the instance recovers. This issue is not addressed in CN200910086514.2 (SIP-based alarm control, relying on central server forwarding, without decoupling design between devices and services) or CN201911242425.2 (subscription-based cloud service alarms, focusing on notification method selection, without decoupling between device access and event handling).

[0009] (2) High number of exposed ports and high network security risks. When deploying multiple instances, each ONVIF device access service instance needs to expose an independent event port (e.g., instance 1 uses port 8081, instance 2 uses port 8082), and the number of ports increases exponentially with the number of instances. In a scenario with tens of thousands of devices accessing the network, if 50 access service instances need to be deployed, more than 50 event ports need to be exposed to the outside world. This not only increases the configuration complexity of the network firewall, but also expands the system's external exposure surface, making it vulnerable to network attacks such as port scanning and malicious connections. CN201811563421.X, based on ONVIF multi-device search access optimization, only solves the problem of device discovery efficiency and does not involve port reuse design. CN202110110685.5, based on ONVIF video management system, focuses on device search and media service processing, and does not have port optimization related technologies. Neither of these technologies has proposed an improvement plan for this risk.

[0010] (3) Lack of load balancing capability and low resource utilization. The binding relationship between devices and ONVIF device access service instances is fixed and unrelated to the actual number of alarm events generated by the devices: If the devices bound to a certain access service instance are mostly high-alarm-frequency devices (such as cameras at shopping mall entrances and exits or traffic intersections), the instance needs to continuously process a large number of event messages, which is prone to CPU and memory overload; while instances bound to low-alarm-frequency devices (such as cameras in unmanned warehouses or idle areas) are in a long-term idle state. Existing solutions cannot dynamically allocate processing resources according to the event traffic volume, resulting in low overall system resource utilization. CN200910157845.0, a hybrid structure alarm processing method, is based on multicast distribution of alarm messages and does not involve load balancing in ONVIF device access scenarios. CN201310397448.7, an event-driven IoT service system, focuses on cross-business domain collaboration and is unrelated to the large-scale ONVIF device event load distribution. Neither of these solutions solves this problem.

[0011] (4) Complex deployment and expansion, high operation and maintenance costs. When adding new ONVIF devices to access service instances, three core operations need to be completed: ① Configure independent ports for new instances; ② Update the platform's device-instance allocation strategy; ③ Existing devices need to re-receive subscription requests from new instances to bind to them. The operation process is cumbersome, and during the expansion, event reporting may be interrupted due to device rebinding, affecting business stability. For example, when the number of platform devices increases from 10,000 to 20,000, 50 new access service instances need to be added. Not only do 50 new ports need to be configured, but about 5,000 devices also need to be reallocated to new instances. During the expansion process, about 10% of the devices will experience a brief interruption in event reporting. CN202011289415.7, Service Instance Deployment Method, focuses on the deployment of service instances and the establishment of cross-domain channels in edge computing scenarios. It does not involve the expansion optimization of ONVIF device event reporting scenarios and does not provide an adaptation solution for this requirement.

[0012] In summary, existing technical solutions face multiple challenges in event alarm reporting scenarios with large-scale ONVIF device access, including reliability, security, resource utilization, and operation and maintenance costs. Related technologies (such as device search, video management, and cloud service alarms) have not provided effective solutions to the above core issues, and there is an urgent need for a new event alarm reporting and processing method to make up for the shortcomings of existing technologies. Summary of the Invention

[0013] In view of the shortcomings of existing technologies, this invention provides an event alarm reporting and processing method for large-scale ONVIF device access. It is applicable to large-scale access scenarios of video surveillance platforms for multi-vendor ONVIF protocol network cameras, NVRs, and other devices, enabling reliable reception, parsing, and reporting of device event alarm messages. The aim is to overcome the shortcomings of existing technologies in large-scale ONVIF device access event alarm reporting scenarios, such as poor reliability, high security risks, low resource utilization, and complex deployment and expansion. The specific objectives are as follows: 1. Improve event service reliability and avoid service interruption. Addressing the problem of one-to-one binding between devices and ONVIF access service instances in existing technologies, and the interruption of event reporting due to single instance failure, this invention constructs an architecture that decouples the ONVIF device access service from the event receiving service. This achieves stateless connection between devices and event processing services—devices can connect to any normal event receiving service on the platform to report events without binding to a specific access service instance. Even if a single service instance fails, it does not affect device event reporting, ensuring service continuity.

[0014] 2. Reduce port exposure and lower network security risks. To address the issue that the number of ports increases exponentially with the number of instances when deploying multiple instances of the existing technology, the event receiving service is designed to share a unified exposed port across multiple instances. This allows only one event receiving port to be exposed in scenarios with large-scale device access, simplifying network firewall configuration, reducing the system's external exposure, and avoiding security risks such as port scanning and malicious connections.

[0015] 3. Achieve event service load balancing and improve resource utilization. To address the uneven load caused by the fixed binding of existing technology devices and access services, this system combines multi-instance deployment of event receiving services with container round-robin strategies to dynamically distribute device event messages to event receiving service instances with lower loads. This avoids overloading of a single instance due to binding to devices with high alarm frequencies, while also preventing resource waste from idle instances and improving the overall resource utilization of the system.

[0016] 4. Simplify deployment and expansion processes and reduce operation and maintenance costs. To address the challenges of expansion where new instances require new port configurations and device rebinding, the stateless architecture based on the event receiving service eliminates the need to adjust port configurations or rebind existing devices when adding new instances. It supports elastic expansion (such as automatic expansion in Kubernetes), reducing business fluctuations during expansion and lowering the complexity and cost of operation and maintenance.

[0017] 5. Ensure event data integrity and reduce alarm loss. To address the issue of devices being unable to report events when access services are abnormal in existing technologies, device channel information is cached through the data sharing center. Even if the ONVIF device access service is abnormal or the device is not displayed as online, the device can still report events through the event receiving service. Moreover, the event receiving service can obtain complete channel information by querying the data sharing center, ensuring that alarm data is not lost and is reported accurately.

[0018] The realization of the purpose of this invention relies on the collaborative architecture of ONVIF device access service, event reception service, and data sharing center. These objectives are interconnected and work together to meet the high reliability, high security, high efficiency, and easy operation and maintenance requirements of event alarm reporting in large-scale ONVIF device access scenarios.

[0019] To achieve the above objectives, the technical solution adopted by the present invention is as follows: a method for reporting and processing event alarms for large-scale ONVIF device access, applied to a security video surveillance platform. The security video surveillance platform includes a functionally decoupled ONVIF device access service, an event receiving service, a data sharing center, and a platform alarm center. The ONVIF device access service and the event receiving service achieve complete separation of event subscription function and event message processing function. The method includes the following steps: (1) Registration of static information of device channel: After the ONVIF device goes online, it actively uploads its own channel static information to the data sharing center. The channel static information includes at least the channel token, device code, and channel number. The data sharing center caches the channel static information; (2) Event subscription request interaction: The ONVIF device access service is only responsible for the connection management of the ONVIF device and the sending of event subscription requests. It does not participate in the reception, parsing, and reporting of event messages. After it actively connects to the ONVIF device, it sends an event subscription request to the ONVIF device. The event subscription request carries the unified network address and unified event port of the event receiving service, as well as the device code and the information used to distinguish between single-channel devices and multi-channel devices. The subscription code of the device type identifier of the equipment; after the ONVIF device receives the event subscription request, it returns a response to the ONVIF device access service; (3) Stateless reporting of event messages: after the ONVIF device triggers the event alarm, it actively connects to the security video surveillance platform based on the unified network address and unified event port subscribed in step (2); the platform dynamically forwards the event message to any normal running event receiving service instance through the dynamic load forwarding strategy; the event receiving service is an independent service that specifically handles the event messages reported by the device, adopts multi-instance deployment and uniformly exposes the unified event port to the outside world, and the event message does not go through the ONVIF device access service; the connection between the event receiving service and the ONVIF device is a stateless connection; (4) Event parsing and channel information query: after the event receiving service receives the event message, it parses the event message according to the ONVIF protocol specification to obtain the channel token, and queries the data sharing center based on the channel token to obtain the device channel information corresponding to the channel token; (5) Complete alarm information reporting: the event receiving service integrates the event message and the corresponding device channel information into complete alarm information and reports it to the platform alarm center to complete the event alarm reporting.

[0020] Furthermore, the dynamic load forwarding strategy is a container round-robin strategy. The specific logic is as follows: the platform monitors the load status of each event receiving service instance in real time. The load status is at least one of the following: CPU utilization, memory usage, or current TCP connection count of the event receiving service instance. When an event message is connected to the platform, the platform will prioritize forwarding the event message to the event receiving service instance with a lower load for processing. The lower load means that the load status of the instance is below a first preset threshold. After processing, the connection is released to avoid event processing delays caused by overload of a single instance. If the load of all event receiving service instances is high, meaning that the load status of all instances is above a second preset threshold, then the event message is forwarded sequentially according to the instance deployment order, and an alarm and automatic scaling mechanism are triggered.

[0021] Furthermore, the stateless connection is manifested in the following ways: each time an ONVIF device triggers an event alarm, it does not need to bind to a specific event receiving service instance, but can connect to any normally operating event receiving service instance within the platform; if the currently connected event receiving service instance is abnormal, such as a server crash or network interruption, the ONVIF device automatically reconnects to other normal event receiving service instances without waiting for the ONVIF device to come back online or re-receive event subscription requests.

[0022] Furthermore, the technical benefits of the unified event receiving service exposing a unified event port are: simplifying the system deployment process, reducing the number of exposed ports to reduce network security risks, such as avoiding port scanning and malicious connections, and eliminating the need to reconfigure ports when expanding the system.

[0023] Furthermore, the channel static information cached in the data sharing center also includes the device model and device software version number. When the channel static information of the ONVIF device changes, such as when a channel is added, deleted, or the device model is updated, the ONVIF device automatically re-uploads the updated channel static information to the data sharing center. After receiving the updated information, the data sharing center refreshes the cached data in real time to ensure the accuracy of channel information queries.

[0024] Furthermore, step (4) of parsing the event message according to the ONVIF protocol specification to obtain the channel token specifically includes: the event receiving service parsing the event message body and extracting the tt:Data node.<tt:SimpleItemName="token"> The field's value serves as the channel token; if parsing fails, such as due to an abnormal event message format,<tt:SimpleItemName="token"> If a field is missing, the event receiving service returns a 400 Bad Request error response to the ONVIF device, requesting the ONVIF device to resend event messages conforming to the ONVIF protocol specification.

[0025] Furthermore, the stateless connection between the event receiving service and the ONVIF device is a short connection: after the ONVIF device sends an event message, it waits for the event receiving service to return the channel information query response, which is the query response in step (4), and then immediately disconnects the connection to avoid occupying network resources for a long time and adapt to the scenario of concurrent reporting by large-scale devices.

[0026] Furthermore, when deploying multiple instances of the event receiving service, the configuration information of each instance is uniformly configured through the environment variables of the security video surveillance platform. The configuration information includes a unified event port, data sharing center access address, and ONVIF protocol parsing rules. When adding a new event receiving service instance, there is no need to modify the event forwarding rules or device subscription information. It can automatically connect to the security video surveillance platform by simply loading the environment variables, thus achieving elastic scaling.

[0027] Furthermore, if the ONVIF device access service is abnormal, such as server crash or network interruption, the ONVIF device that has completed channel static information registration and has received event subscription requests in the past can still report event messages to the event receiving service normally based on the unified network address and unified event port of the event receiving service subscribed in step (2); the event receiving service can still obtain complete device channel information by querying the data sharing center, thus avoiding the loss of event alarms.

[0028] Furthermore, after receiving complete alarm information, the platform alarm center also performs the following operations: storing the complete alarm information in the alarm database according to the classification rules of device code and event type; triggering multi-dimensional alarm notifications, including interface pop-ups, audio and visual prompts, SMS notifications, or email notifications; and recording alarm processing logs, which include alarm reception time, alarm processing status, and handler information, to facilitate subsequent alarm traceability and statistical analysis.

[0029] Furthermore, the device code in the subscription code serves as a unique identifier for the ONVIF device, ensuring that the event receiving service can initially identify the device from which the event originates through the subscription code. For single-channel devices, the event receiving service can directly associate alarm information based on the device code in the subscription code. For multi-channel devices, it is necessary to query the data sharing center using the channel token obtained by parsing the event message to further determine the specific channel information.

[0030] The present invention adopts the above technical solution, and has the following specific beneficial effects: In the present invention, by constructing an architecture that completely separates the ONVIF device access service and the event receiving service functions, the event receiving service and the device are completely decoupled. When the device triggers an event alarm, it can connect to any normally operating event receiving service instance in the platform to process the event message, and the connection between the two is a stateless connection; at the same time, the states of the device and the ONVIF device access service do not affect each other. Even if the ONVIF device access service is abnormal, such as a server crash or network interruption, the device that has completed channel information registration can still report events normally based on the historically subscribed event receiving service address and port, completely breaking the limitation of one-to-one binding between the device and the service instance in the prior art, and effectively avoiding event service interruption.

[0031] In this invention, the event receiving service achieves load balancing for event processing based on each event connection: the platform monitors the load status of each event receiving service instance in real time through a dynamic load forwarding strategy (such as a container round-robin strategy), prioritizes forwarding event messages to instances with lower loads, and only forwards them sequentially according to the instance deployment order when all instances are under high load. This design avoids the problem in existing technologies where fixed binding between devices and services leads to some instances being overloaded due to processing high-alarm-frequency device messages, while some instances are idle due to binding to low-alarm-frequency devices. It makes full use of the hardware resources of each instance and significantly improves the overall resource utilization of the system.

[0032] In this invention, the event receiving service adopts a stateless multi-instance architecture, eliminating the possibility of business volume exceeding the management capacity of a single service. When business volume increases, horizontal scaling can be achieved as long as the scaling conditions are met, and no new ports need to be exposed during the scaling process. When the event receiving service is deployed in multiple instances, a single event receiving port is exposed externally, eliminating the need to configure multiple independent ports as required by existing multi-instance deployment technologies. This simplifies the network firewall configuration process, reduces network security risks such as port scanning and malicious connections, and avoids business fluctuations caused by port configuration and device rebinding during scaling, significantly reducing operation and maintenance costs.

[0033] In this invention, the platform ensures high service reliability through multi-instance deployment of the event receiving service: even if a single event receiving service instance crashes and goes offline, it can still automatically connect to other normally operating instances when a device triggers an event, without waiting for the device to come back online or re-receive the event subscription request, and will not affect the event reporting service; effectively solving the problem of event service interruption caused by the abnormality of a single service instance in the prior art, realizing high availability of the event reporting service, and adapting to the business continuity requirements in large-scale ONVIF device access scenarios.

[0034] In this invention, the static channel information of ONVIF devices (including at least the channel token, device code, and channel number, and may also include the device model and software version number) is cached through the data sharing center. When the static channel information of the device changes, it is automatically re-uploaded to the data sharing center to refresh the cache. Even if the device is not displayed as online or the ONVIF device access service is abnormal, the event receiving service can still query the data sharing center by parsing the channel token in the event message to obtain the complete device channel information. This ensures that the event message is accurately associated with the device channel information before being reported to the platform alarm center, avoiding alarm data loss and ensuring the integrity of event data.

[0035] In this invention, the subscription code in the event subscription request includes a device code and a device type identifier used to distinguish between single-channel and multi-channel devices. The event receiving service can initially identify the device from which the event originates through the subscription code. For single-channel devices, alarm information association can be completed directly based on the device code in the subscription code. For multi-channel devices, the specific channel information can be determined by querying the data sharing center in conjunction with the channel token obtained by parsing the event message. This design improves the accuracy of alarm information location and facilitates the platform alarm center to classify and store alarm information according to device code and event type, trigger multi-dimensional notifications, and record processing logs, providing convenience for subsequent alarm tracing. Attached Figure Description

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

[0037] Figure 1 is a schematic diagram of the existing technology process.

[0038] Figure 2 is a flowchart of the event alarm reporting and processing method of the present invention.

[0039] Figure 3 is a schematic diagram of the system interaction of the present invention.

[0040] Figure 4 is a timing diagram of the event alarm reporting and processing method of the present invention. Detailed Implementation

[0041] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the invention as detailed in the appended claims.

[0042] As shown in Figure 2, this embodiment provides an event alarm reporting and processing method for large-scale ONVIF device access, applied to a security video surveillance platform. The security video surveillance platform includes a functionally decoupled ONVIF device access service, event receiving service, data sharing center, and platform alarm center. The ONVIF device access service and event receiving service achieve complete separation of event subscription function and event message processing function. The method includes the following steps: (1) Device channel static information registration: After the ONVIF device goes online, it actively uploads its own channel static information to the data sharing center. The channel static information includes at least the channel token, device code, and channel number. The data sharing center caches the channel static information. This registration process is driven by the ONVIF device access service: First, it obtains the original information from the device, and then organizes it into a structured data format (e.g., a lightweight data exchange format), and writes it to the data sharing center through the internally defined application programming interface. The data sharing center stores the device code or channel identifier as the primary key to ensure efficient querying through key values ​​later.

[0043] (2) Event Subscription Request Interaction: The ONVIF Device Access Service is only responsible for the connection management of ONVIF devices and the sending of event subscription requests. It does not participate in the reception, parsing, and reporting of event messages. After actively connecting to an ONVIF device, it sends an event subscription request to the ONVIF device. The event subscription request carries the unified network address and unified event port of the event receiving service, as well as a subscription code containing the device code and a device type identifier used to distinguish between single-channel and multi-channel devices. After receiving the event subscription request, the ONVIF device returns a response to the ONVIF Device Access Service. When constructing the subscription request, the callback address field used to receive event notifications is set to the unified entry point of the event receiving service cluster, rather than the network address of the access service itself. The subscription code is usually embedded in the path part of the callback address or placed in a custom header of the request message.

[0044] (3) Stateless reporting of event messages: After the ONVIF device triggers an event alarm, it actively connects to the security video surveillance platform based on the unified network address and unified event port subscribed in step (2); the platform dynamically forwards the event messages to any normally operating event receiving service instance through a dynamic load forwarding strategy; at the network entry point of the platform, a dedicated traffic distribution component (i.e., load balancer) is deployed. This component continuously checks the health status of each backend event receiving service instance and, according to a preset scheduling algorithm (such as a weighted round-robin algorithm or a least-connection algorithm), distributes the event connection requests sent by the device to currently available instances with relatively low loads for processing in real time. The event receiving service is an independent service that specifically handles event messages reported by devices. It is deployed in multiple instances and exposes a unified event port to the outside world. Event messages do not pass through the ONVIF device access service. The connection between the event receiving service and the ONVIF device is a stateless connection. (4) Event parsing and channel information query: After receiving the event message, the event receiving service parses the event message according to the ONVIF protocol specification to obtain the channel token, and queries the data sharing center based on the channel token to obtain the device channel information corresponding to the channel token. The parsing process includes two main steps: First, the subscription code is parsed from the request message to obtain the device code and device type. Second, the extended markup language format text of the event message is parsed to locate the specified data node and read the value of the sub-item named "identifier" as the channel identifier. When querying, the event receiving service calls the internal network and requests the corresponding complete channel mapping information from the data sharing center based on the channel identifier.

[0045] (5) Complete Alarm Information Reporting: The event receiving service integrates the event message with the corresponding device channel information into complete alarm information and reports it to the platform alarm center, thus completing the event alarm reporting. The integration process combines the original event details with the queried channel information into an internally defined standard alarm data object. This object is usually sent to the platform alarm center through asynchronous message middleware or direct internal service calls to achieve decoupling between services and communication reliability.

[0046] As one implementation method, the dynamic load forwarding strategy in this embodiment is a container round-robin strategy. The specific logic is as follows: The platform monitors the load status of each event receiving service instance in real time. When an event message connects to the platform, the platform prioritizes forwarding the event message to an event receiving service instance with a lower load for processing. After processing, the connection is released to avoid delays in event processing due to overload of a single instance. If all event receiving service instances have high loads, event messages are forwarded sequentially according to the instance deployment order, triggering alarms and automatic scaling mechanisms. "Low load" means the instance's load status is below a first preset threshold, and "high load" means the load status of all instances is above a second preset threshold. In this embodiment, the first preset threshold can be set to at least one of CPU utilization of 40%, memory utilization of 50%, or current TCP connection count of 1000. The second preset threshold can be set to at least one of CPU utilization of 80%, memory utilization of 85%, or current TCP connection count of 3000. Load status monitoring relies on a container orchestration platform or independent monitoring agent to continuously collect metrics such as CPU utilization, memory utilization, and current TCP connection count of each instance. The traffic distribution component dynamically adjusts the priority or proportion of its distribution requests to each instance based on these real-time metrics.

[0047] This strategy effectively solves the problem of uneven load caused by the fixed binding of existing technology devices and services by dynamically allocating processing instances based on each event connection. It avoids the situation where devices with high alarm frequency are concentratedly overloaded and instances corresponding to devices with low alarm frequency are idle, making full use of the CPU and memory resources of each instance, significantly improving the overall resource utilization of the system, and adapting to the event concurrency processing needs of large-scale ONVIF device access scenarios with tens of thousands of devices.

[0048] As one implementation method, the stateless connection in this embodiment manifests as follows: Each time an ONVIF device triggers an event alarm, it does not need to bind to a specific event receiving service instance; it can connect to any normally functioning event receiving service instance within the platform. If the currently connected event receiving service instance malfunctions, such as due to server crashes or network interruptions, the ONVIF device automatically reconnects to other normal event receiving service instances without waiting for the ONVIF device to re-enter or re-receive event subscription requests. The automatic reconnection mechanism on the device side is implemented by its built-in protocol stack or software toolkit. When the initial connection attempt fails (e.g., due to network timeout or server error response), the device simply uses the same network address and port previously obtained from the subscription to attempt a reconnection. Since the traffic distribution component has removed the faulty instance from the available list, the retry request is automatically redirected to other healthy instances.

[0049] This stateless connection design achieves complete decoupling between the event receiving service and the device. The states of the device and the ONVIF device access service do not interfere with each other. Even if an event receiving service instance crashes and goes offline, it will not cause the device event service to be interrupted. This completely solves the defect of existing technology where the event reporting of bound devices is interrupted due to the abnormality of a single service instance, and ensures the high availability and continuity of event services.

[0050] As one implementation method, the technical effect of exposing a unified event port for the event receiving service in this embodiment is as follows: it simplifies the system deployment process, reduces the number of exposed ports to lower network security risks, such as avoiding port scanning and malicious connections, and eliminates the need to reconfigure ports when expanding the system. Compared to the existing technology's design of "multiple instances needing to expose multiple independent ports," this embodiment only needs to expose one event receiving port, significantly reducing the system's external exposure surface—this reduces the configuration complexity of the network firewall, decreases security risks such as port scanning and malicious intrusion, and solves the problem of "new ports needing to be configured for new instances" when expanding the system, laying the foundation for subsequent elastic expansion.

[0051] As one implementation method, the channel static information cached in the data sharing center in this embodiment also includes the device model and device software version number. When the channel static information of the ONVIF device changes, such as when a channel is added, deleted, or the device model is updated, the ONVIF device automatically re-uploads the updated channel static information to the data sharing center. Upon receiving the updated information, the data sharing center refreshes the cached data in real time, ensuring the accuracy of channel information queries. By persistently caching channel static information, the data sharing center provides a stable source of "channel token-device information" mapping for the event receiving service. Even if the ONVIF device access service is abnormal or the device is not displayed as online, the event receiving service can still query the complete channel information through the token, effectively solving the problem of "alarm data loss due to access service abnormalities" in existing technologies, and ensuring the integrity of event data and the accuracy of alarm reporting.

[0052] As one implementation method, in this embodiment, step (4) of parsing the event message according to the ONVIF protocol specification to obtain the channel token specifically includes: the event receiving service parsing the event message body and extracting the tt:Data node.<tt:SimpleItemName="token"> The field's value serves as the channel token; if parsing fails, such as due to an abnormal event message format,<tt:SimpleItemName="token"> If a field is missing, the event receiving service returns a "400 Bad Request" error response to the ONVIF device, requiring the ONVIF device to resend event messages conforming to the ONVIF protocol specifications. Strictly adhering to the ONVIF protocol specifications in token parsing ensures the accuracy of channel identifier extraction, providing a reliable basis for subsequent queries of the data sharing center and associated device channel information. This avoids issues where alarm information cannot be matched with the device due to incorrect token parsing, ensuring the accuracy of alarm reporting.

[0053] As one implementation method, the stateless connection between the event receiving service and the ONVIF device in this embodiment is a short connection: after the ONVIF device sends an event message, it waits for the event receiving service to return a channel information query response, which is the query response in step (4), and then immediately disconnects the connection to avoid occupying network resources for a long time, thus adapting to the scenario of concurrent reporting by a large number of devices. The short connection design follows the principle of "disconnecting after event processing", and will not occupy the network resources of the device and the platform for a long time. Even if tens of thousands of devices trigger event alarms at the same time, it can avoid the continuous occupation of network bandwidth, ensure that the event messages of each device can be transmitted quickly, and further improve the system response efficiency when a large number of devices report concurrently.

[0054] As one implementation method, in this embodiment, when multiple instances of the event receiving service are deployed, the configuration information of each instance is uniformly configured through the environment variables of the security video surveillance platform. The configuration information includes a unified event port, data sharing center access address, and ONVIF protocol resolution rules. When adding a new event receiving service instance, there is no need to modify the event forwarding rules or device subscription information; simply loading the environment variables is sufficient for automatic access to the security video surveillance platform, achieving elastic scaling. In a container-based deployment environment, these configurations are injected when the container starts. Combined with a container orchestration platform, services can be described by defining deployment resources and configuring automatic scaling strategies. These strategies automatically adjust the number of running instances based on metrics such as processor or memory utilization. When a new instance starts, it is automatically registered by the service discovery mechanism and identified by the traffic distribution component, thus immediately beginning to share business traffic.

[0055] This configuration method is based on the stateless architecture of the event receiving service, which solves the scaling problem of existing technologies that require "configuring new ports and rebinding devices when adding new instances" - when scaling up, there is no need to adjust the subscription information of the online devices or modify the firewall port configuration. It supports container orchestration tools such as Kubernetes to achieve automatic scaling, which greatly simplifies operation and maintenance and reduces the risk of business fluctuations during scaling up.

[0056] As one implementation method, if the ONVIF device access service is abnormal in this embodiment, such as a server crash or network interruption, the ONVIF device that has completed channel static information registration and has historically received event subscription requests can still report event messages to the event receiving service normally based on the unified network address and unified event port of the event receiving service subscribed in step (2). The event receiving service can still obtain complete device channel information by querying the data sharing center, thus avoiding the loss of event alarms. This design completely breaks the limitation of the existing technology that "device event reporting depends on the access service". Even if the ONVIF device access service is abnormal, the device can still complete event reporting based on the historically subscribed address and port. Moreover, the event receiving service can obtain complete device information through the data sharing center, further ensuring the reliability of event services and reducing the loss of alarms due to service abnormalities.

[0057] As one implementation method, after receiving complete alarm information, the platform alarm center in this embodiment also includes the following operations: storing the complete alarm information to the alarm database according to the classification rules of device code and event type; triggering multi-dimensional alarm notifications, including interface pop-ups, audio-visual prompts, SMS notifications, or email notifications; and recording alarm processing logs, which include alarm reception time, alarm processing status, and handler information, facilitating subsequent alarm tracing and statistical analysis. Through the combined operations of "classified storage, multi-dimensional notifications, and log recording," the problems of chaotic alarm management and difficult tracing in existing technologies are solved—it allows managers to quickly locate the alarm source (by device code) and distinguish alarm types, while multi-dimensional notifications ensure timely alarm information delivery. Simultaneously, log recording provides data support for subsequent alarm processing review and business statistics, improving the platform's alarm management efficiency.

[0058] As one implementation method, in this embodiment, the device code in the subscription code serves as a unique identifier for the ONVIF device, ensuring that the event receiving service can initially identify the event source device through the subscription code. For single-channel devices, the event receiving service can directly complete alarm information association based on the device code in the subscription code. For multi-channel devices, it is necessary to query the data sharing center using the channel token obtained by parsing the event message to further determine the specific channel information. The subscription code, through the combined design of "device code and type identifier," enables rapid identification and differentiated processing of the event source device—single-channel devices can complete alarm association without additional queries, while multi-channel devices can locate the specific channel by querying the token. This improves the efficiency of alarm information association and avoids the problem of ambiguous alarm location caused by missing channel information in multi-channel devices, ensuring the accuracy of alarm information.

[0059] The large-scale ONVIF device access event alarm reporting and processing method provided in this embodiment is based on the core design concepts of functional decoupling, stateless architecture, and unified resource management. It constructs a complete solution for registration, subscription, reporting, parsing, and alarming based on four decoupled modules: ONVIF device access service, event receiving service, data sharing center, and platform alarm center. By separating the functions of the ONVIF device access service and event receiving service, the limitation of "subscription and processing binding" in existing technologies is completely broken. Device event reporting does not depend on the access service status, fundamentally improving business reliability. When a device comes online, it actively uploads channel static information to the data sharing center, providing data support for subsequent event parsing. The access service is only responsible for sending subscription requests containing "unified address, unified port, and subscription code." After a device triggers an event, it accesses the platform through a stateless connection. The container polling strategy dynamically allocates events to low-load event receiving service instances; the event receiving service parses the token and queries the data sharing center, integrates the information, and reports it to the platform's alarm center, forming a closed loop. This solution reduces security risks and scaling complexity through "unified port exposure," achieves balanced resource utilization through "dynamic load forwarding," adapts to large-scale concurrency through "stateless short connections," ensures data integrity through the "data sharing center," and improves alarm accuracy through "subscription encoding differentiation processing." This solution comprehensively addresses the five core problems of existing technologies in large-scale ONVIF device access scenarios: poor reliability, high security risks, uneven load, complex scaling, and easy data loss. It adapts to the access needs of tens of thousands of devices, while simplifying operation and maintenance processes and reducing management costs, providing efficient and stable technical support for large-scale device event management in security video surveillance platforms.

[0060] Figure 3 shows a service deployment and interaction diagram of this embodiment (the diagram shows the interaction relationship of the core components of the VisionLink monitoring platform: including ONVIF access service, event receiving service, platform alarm center and devices. Each component interacts through the links of "1 event subscription", "3 event message", "4 response" and "5 alarm notification reporting", clarifying the connection logic between the device and each service); Figure 4 shows a business process sequence diagram of this embodiment (the diagram presents the complete business link in chronological order: after the device goes online, it uploads channel information and obtains a return response; the ONVIF access protocol sends an event subscription carrying device code, address and port information; the device returns a response; the device reports event information; the event receiving service uses a token to obtain channel information from the data sharing center and returns a response; the event receiving service uploads event alarm information to the platform alarm center).

[0061] The event alarm reporting and processing method for large-scale ONVIF device access provided in this embodiment is based on adding an event receiving service and including device code and other information in the event subscription request of the ONVIF device access service. This enables the front-end device and the event receiving service to achieve stateless and decoupled connection, while relying on the data sharing center to ensure the sharing and accuracy of channel information.

[0062] The normal process is as follows: The ONVIF device access service actively connects to the device and sends an event subscription message containing the event receiving service address and port information. The device receives the message and returns a response. After the device triggers an event, it actively connects to the event receiving service and sends an event message. The event receiving service receives the event message, parses it, and reports the alarm information to the platform alarm center.

[0063] The event receiving service primarily receives event messages sent by devices. After parsing the channel token and associating it with the device channel information, it forwards the complete alarm information to the platform's alarm center. It exposes the same port externally, and the address information (address and port) carried by the ONVIF device access service when subscribing to events to devices is consistent. Devices connect to the platform through this unified address and port, and the load balancer distributes the messages to the event receiving service. If the currently distributed event receiving service is faulty, the device will re-initiate the connection, and the load balancer will forward it to a normal event receiving service instance, ensuring continuous service operation. For load balancing, the platform uses a container round-robin strategy to forward event messages to the event receiving service, thereby achieving load balancing.

[0064] The event receiving service adopts a multi-instance deployment mode, and the address and port information can be configured in the environment variables of the ONVIF device access service. After the device comes online, the event subscription request will use these configuration information.

[0065] The specific business steps are as follows (as shown in the business process sequence diagram in Figure 4): After the ONVIF device comes online, it uploads its own channel information to the data sharing center; the ONVIF device access service sends an event subscription request to the device, adding the device code and device type (to distinguish between single-channel / multi-channel devices) to the subscription code, and also including the server address and port for receiving event messages, so as to facilitate the device to connect to the platform and send event messages; after the device triggers an event alarm, it actively connects to the platform, and the platform forwards the event message to the event receiving service through a container polling strategy; after receiving the event message, the event receiving service parses out the channel token information, accesses the data sharing center to obtain the corresponding channel information, and finally reports the event alarm information to the platform alarm center.

[0066] The data format for event subscription is shown below: <subscribe> <consumerreference> <a:address>[Unified Network Address]:[Unified Event Port] / subscription_[Device Code]_[Device Type Identifier]< / a:address> < / consumerreference> <initialterminationtime> PT60S< / initialterminationtime> < / subscribe> Among them, [Unified Network Address] and [Unified Event Port] correspond to the unified access entry exposed to the outside world by the event receiving service cluster, which are used to inform the device of the target location for event reporting.

[0067] The subscription_[device code]_[device type identifier] is the subscription code. The [device code] is a unique identifier for the device; the [device type identifier] is used to distinguish the device type. For example, a "0" at the end indicates a multi-channel device (such as an NVR), and a "1" at the end indicates a single-channel device (such as an IPC).

[0068] Device channel information is typically relatively stable. Each time a device comes online, it uploads its channel information to the data sharing center. When channel information changes (e.g., channels are added or deleted), the device uploads it again to refresh the data and ensure its validity. The data sharing center stores information including the mapping relationship between channel tokens and device channels (e.g., device code, channel code, channel number, etc.). When the event receiving service parses the token from the event message, it can use that token to query the data sharing center to obtain the corresponding device channel number, code, and other information, thereby completing the event reporting.

[0069] In the video surveillance platform, the ONVIF device access service is only responsible for device connection and event subscription (using the device code as the unique identifier for subscription to distinguish devices). Event message processing is handled by the event receiving service. The event receiving service distinguishes devices based on the subscription code, parses the event type, and sends it to the alarm center. This does not rely on the connection status between the ONVIF device access service and the device, achieving isolation between event services and the device access service. After completing device registration, the ONVIF device access service obtains channel information from the device and uploads it to the data sharing center (single-channel devices do not require additional upload operations). The device code is included during subscription to facilitate event source differentiation; the platform's alarm data includes device channel information and alarm type, etc., with the default channel number for single-channel devices being 0. After a device triggers an event, it actively connects to the event receiving service and sends an event message: single-channel devices can directly complete event reporting via the subscription code; multi-channel devices need to further parse the event message to obtain the channel token, then query the channel information corresponding to that token through the data sharing center to finally complete event reporting.

[0070] The address information obtained by the device points to a platform node (rather than a specific container or service instance). Theoretically, it can connect to any live event receiving service within the node, without fixed directionality (in this embodiment, the device and the event receiving service are not bound together, and can flexibly connect to any normal instance). Therefore, as long as not all event receiving services within the platform are offline, the business will not be affected, achieving high availability of the event receiving service. Simultaneously, the connection between the device and the event receiving service is stateless, allowing it to connect to any event receiving service instance within the platform; and the event business uses short connections (disconnecting immediately after event processing). The platform distributes device connections to event receiving services through a polling strategy, achieving load balancing for business processing. The platform service is deployed in a containerized manner. When the event receiving service is detected to be overloaded, it can automatically scale up to meet the needs of high-concurrency business scenarios, eliminating bottlenecks in single-service processing capacity, and scaling up does not require exposing new ports.

[0071] The core advantages are: the event receiving service is completely decoupled from the device, the connection is stateless, and the state of the device and the access service does not affect the interaction between the event receiving service and the device; load balancing of event services is achieved based on each event connection; the stateless multi-instance architecture supports horizontal scaling, and can automatically expand when the business volume increases without adding new ports; multi-instance deployment ensures reliability, and the failure or offline of a single event receiving service will not interrupt the business, achieving high availability.

[0072] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A method for reporting and processing event alarms for large-scale ONVIF device access, characterized in that: Includes the following steps: In the processing method, the ONVIF device access service and the event receiving service achieve complete separation of the event subscription function and the event message processing function; (1) After the ONVIF device is online, it actively uploads its own channel static information to the data sharing center; (2) The ONVIF device access service is only responsible for the connection management of the ONVIF device and the sending of event subscription requests, and does not participate in the reception, parsing and reporting of event messages; After it actively connects to the ONVIF device, it sends an event subscription request to the ONVIF device; After receiving the event subscription request, the ONVIF device returns a response to the ONVIF device access service; (3) After the ONVIF device triggers an event alarm, it actively connects to the platform based on the unified network address and the unified event port; The platform uses a dynamic load forwarding strategy to dynamically forward event messages to any normally running event receiving service instance; the event receiving service is an independent service that specifically handles event messages reported by the device, and it adopts multi-instance deployment and exposes a unified event port to the outside world. The event messages do not go through the ONVIF device access service; the connection between the event receiving service and the ONVIF device is a stateless connection; (4) After receiving the event message, the event receiving service parses the event message according to the ONVIF protocol specification to obtain the channel token, and queries the data sharing center based on the channel token to obtain the device channel information corresponding to the channel token; (5) The event receiving service integrates the event message and the corresponding device channel information into a complete alarm message and reports it to the platform alarm center.

2. The method according to claim 1, characterized in that: The dynamic load forwarding strategy is a container round-robin strategy. The specific logic is as follows: The platform monitors the load status of each event receiving service instance in real time. The load status is at least one of the following: CPU utilization, memory usage, or current TCP connection count of the event receiving service instance. When an event message connects to the platform, the platform will prioritize forwarding the event message to the event receiving service instance with a lower load for processing. A lower load means the instance's load status is below a first preset threshold. After processing, the connection is released to avoid delays in event processing due to overload of a single instance. If all event receiving service instances have a high load (meaning all instances' load status is above a second preset threshold), then event messages are forwarded sequentially according to the instance deployment order, triggering alarms and an automatic scaling mechanism.

3. The method according to claim 1, characterized in that: Stateless connectivity manifests itself in the following ways: each time an ONVIF device triggers an event alarm, it does not need to bind to a specific event receiving service instance and can connect to any normally operating event receiving service instance within the platform; if the currently connected event receiving service instance is abnormal, the server crashes, or the network is interrupted, the ONVIF device automatically reconnects to other normal event receiving service instances without waiting for the ONVIF device to come back online or re-receive event subscription requests.

4. The method according to claim 1, characterized in that: The channel static information cached in the data sharing center also includes the device model and device software version number. When the channel static information of the ONVIF device changes, including adding or deleting a channel or updating the device model, the ONVIF device automatically re-uploads the updated channel static information to the data sharing center. After receiving the updated information, the data sharing center refreshes the cached data in real time to ensure the accuracy of channel information queries.

5. The method according to claim 4, characterized in that: Step (4) involves parsing the event message according to the ONVIF protocol specification to obtain the channel token. Specifically, this includes: the event receiving service parsing the event message body and extracting the tt:Data node.<tt:SimpleItemName="token"> The value of the field serves as the channel token; if parsing fails, the event receiving service returns an error response to the ONVIF device, requesting the ONVIF device to resend the event message conforming to the ONVIF protocol specification.

6. The method according to claim 3, characterized in that: The stateless connection between the event receiving service and the ONVIF device is a short connection: after the ONVIF device sends an event message, it waits for the event receiving service to return the channel information query response, and then immediately disconnects the connection.

7. The method according to claim 1, characterized in that: When deploying multiple instances of the event receiving service, the configuration information of each instance is uniformly configured through the environment variables of the security video surveillance platform. The configuration information includes a unified event port, data sharing center access address, and ONVIF protocol parsing rules. When adding a new event receiving service instance, there is no need to modify the event forwarding rules or device subscription information. It can automatically connect to the security video surveillance platform by simply loading the environment variables, thus achieving elastic scaling.

8. The method according to claim 1 or 4, characterized in that: If the ONVIF device access service is abnormal, the server crashes or the network is interrupted, the ONVIF device that has completed the static information registration of the channel and has received event subscription requests in the past can still report event messages to the event receiving service normally based on the unified network address and unified event port of the event receiving service subscribed in step (2); the event receiving service can still obtain complete device channel information by querying the data sharing center, thus avoiding the loss of event alarms.

9. The method according to claim 1, characterized in that: After receiving complete alarm information, the platform alarm center also performs the following operations: storing the complete alarm information in the alarm database according to the classification rules of device code and event type; triggering multi-dimensional alarm notifications, including interface pop-ups, audio and visual prompts, SMS notifications or email notifications. Record alarm processing logs, which include alarm reception time, alarm processing status, and information of the person handling the alarm, to facilitate subsequent alarm tracing and statistical analysis.

10. The method according to claim 1, characterized in that: The device code in the subscription code serves as a unique identifier for the ONVIF device, ensuring that the event receiving service can initially identify the device from which the event originates. For single-channel devices, the event receiving service can directly associate alarm information based on the device code in the subscription code. For multi-channel devices, it is necessary to query the data sharing center using the channel token obtained by parsing the event message to further determine the specific channel information.

Images