Landscape lighting isomerization device unified management and control method, system and storage medium

Abstract

The application provides a landscape lighting heterogeneous device unified management and control method and system and a storage medium, wherein the method steps comprise: abstracting the functional units of heterogeneous devices into standardized capability points, completing device semantic definition, and constructing a unified device capability abstraction model; building an edge computing architecture for cloud-edge collaboration, model matching and dynamic instantiation of the access device according to the unified device capability abstraction model, generating a device digital twin, and compiling a twin instruction that can standardize the calling of a digital twin standardized application program interface; performing edge-end collaborative control, converting the twin instruction into a device native protocol on the edge side, and executing pre-stored light control instructions based on the edge side local computing and caching capabilities. Thus, the fundamental technical problem of being unable to centrally manage and control and high-precision synchronous linkage of cross-brand and heterogeneous light master control devices is solved.

Description

Technical Field

[0001] This invention relates to the field of IoT industrial control technology, and in particular to a unified management and control method, system and storage medium for heterogeneous landscape lighting devices based on cloud-edge-device collaboration. Background Technology

[0002] With the rapid development of smart cities and the nighttime economy, landscape lighting systems are evolving from static lighting control of individual buildings or a few buildings to a digital infrastructure that enables multi-park and city-wide interconnection and dynamic interaction. Currently, mainstream landscape lighting centralized control solutions in the industry have several fundamental architectural flaws when dealing with the access and collaborative control of large-scale, heterogeneous devices. This leads to serious resource waste and technical bottlenecks in actual multi-park, phased construction projects and city-wide landmark interconnection scenarios.

[0003] The varying construction progress across different industrial parks has led to inconsistencies in the lighting control systems used in the bidding process. Furthermore, fragmented equipment control protocols have resulted in incompatibility between existing lighting control systems in completed parks and those in parks under construction, as well as between systems from different brands. Integrating these systems requires either a complete, costly replacement or multiple, isolated management systems, which are cumbersome and complex for end-users, hindering the timely synchronization of lighting performance.

[0004] Most common centralized control solutions on the market are based on a point-to-point direct communication mode between the cloud and the main lighting control device. This mode easily exposes fundamental flaws when dealing with city-wide multi-park interconnection scenarios:

[0005] For example, management complexity and resource consumption: The cloud needs to establish and maintain independent communication links and session states with dozens to hundreds of third-party lighting controllers within the park. This not only leads to an exponential increase in the number of cloud connections, threads, and port resources, but also drastically increases the complexity of device management and status maintenance, resulting in poor system scalability. Low data distribution efficiency: When large performance files or unified instructions need to be issued, the cloud must initiate parallel "point-to-point" repeated transmissions to each terminal, consuming a large amount of uplink bandwidth. Poor network dependence and stability: The availability of each controller directly depends on the stability of its complex public network link with the cloud. Network fluctuations in any link can cause the corresponding device to malfunction, miss scheduled execution times, and result in asynchronous performances. In large-scale coordinated performances, this can easily trigger the spread of single-point failures, leading to low overall system reliability.

[0006] Therefore, these methods are typically limited to managing devices of the same brand and system, and their limited open interfaces are designed for use within a single campus, failing to address the issue of unified management across brands and systems in an architectural way. Furthermore, even if some solutions attempt to introduce time synchronization, the accuracy and reliability of their "point-to-point" calibration cannot meet the stringent requirements of millisecond-level and frame-level precise coordination among hundreds of heterogeneous devices.

[0007] Although cloud-edge-device collaborative architecture has been explored in the field of IoT, none of the currently available technical solutions have proposed an effective solution for the specific technical problem of non-destructive integration and high-precision synchronous control of existing heterogeneous lighting main control systems in multi-park linkage of landscape lighting. Summary of the Invention

[0008] Therefore, the main objective of this invention is to provide a unified management and control method, system, and storage medium for heterogeneous landscape lighting equipment, in order to solve the fundamental technical problem of the inability to centrally manage and achieve high-precision synchronous linkage of multi-brand, heterogeneous lighting main control equipment.

[0009] To achieve the above objectives, according to one aspect of the present invention, a method for unified management and control of heterogeneous landscape lighting devices is provided, the steps of which include:

[0010] Step S100: Abstract the functional units of heterogeneous devices into standardized capability points, complete the semantic definition of devices, and build a unified device capability abstraction model;

[0011] Step S200: Build a cloud-edge collaborative edge computing architecture. Based on the unified device capability abstract model, perform model matching and dynamic instantiation of the access devices to generate device digital twins and compile twin instructions that can call the standardized application programming interface of the digital twins in a standardized manner.

[0012] Step S300: Perform edge-to-edge collaborative control, complete the conversion of twin commands to the device's native protocol through the edge side, and execute the pre-stored lighting control commands in real time based on the edge side's local computing and caching capabilities.

[0013] In a possible preferred embodiment, the step of abstracting the functional units of heterogeneous devices into standardized capability points in step S100 includes:

[0014] Define a semantic identity module to store globally unique capability IDs, business-oriented capability names, and device IP addresses and port information;

[0015] Define the communication protocol and instruction template module, specify the underlying communication protocol corresponding to the implemented capability, provide parameterized instruction message templates and declare the corresponding physical parameters;

[0016] Define the API mapping module to specify the specific service interfaces that the edge side needs to call when executing capabilities;

[0017] Define the expected feedback parsing rules module, set the parsing rules for the device's original return messages, and realize the conversion of the original byte stream into standardized business data;

[0018] Define the interaction interface contract module, and set the data structure, type, and value range of the standardized input and output parameters for calling capabilities.

[0019] In a possible preferred embodiment, the step of building a cloud-edge collaborative edge computing architecture in step S200 includes:

[0020] By containerizing edge computing middleware and rule engine deployment, a three-layer architecture is constructed, consisting of a device protocol adaptation layer, a lighting control abstraction layer, and an edge service management layer. This architecture enables model matching and dynamic instantiation of access devices to achieve dual-track binding of semantic and protocol binding. Furthermore, based on cloud-edge collaboration, digital twins of devices and standardized application programming interfaces are generated, supporting visualized scene policy orchestration and collaborative execution.

[0021] In a possible preferred embodiment, the device protocol adaptation layer is a hot-swappable driver plug-in management framework that enables bidirectional conversion between standardized commands and the device's native protocols; the lighting control abstraction layer encapsulates the lighting control core engine in a containerized manner and provides a standardized application programming interface to complete the conversion of standardized control commands; the edge service management layer runs as a daemon process, integrates various basic services, and is responsible for edge system management and service scheduling.

[0022] In a possible preferred embodiment, the dual-track binding step includes:

[0023] After the edge device starts up, it performs device discovery, collects the unique encoding information of the device, and reports it to the cloud platform via the MQTT protocol. The cloud platform queries the device capability model library to complete the matching, instantiates and generates a device-specific configuration list and distributes it. The edge device loads the corresponding driver plugin and injects the device communication parameters according to the configuration list, and completes the protocol driver readiness.

[0024] In a possible preferred embodiment, the steps of generating a digital twin of the device based on cloud-edge collaboration and a standardized application programming interface, and completing the orchestration and collaborative execution of visualization scene strategies include:

[0025] After the device is instantiated, the cloud platform creates a digital twin of the physical device in the form of a standardized application programming interface (API) that is bound to all capability points. Based on this standardized API, the platform completes the orchestration of visual scenario strategies and compiles them into a twin instruction sequence. After being sent to the edge, the rule engine converts it into a local execution task graph and schedules the edge core service resources according to the time sequence and dependencies, thus completing the protocol conversion and instruction execution in a closed loop.

[0026] To achieve the above objectives, according to another aspect of the present invention, a unified management and control system for heterogeneous landscape lighting equipment is also provided, for executing any of the methods described above, comprising: a cloud-based intelligent management and control unit, a secure communication network unit, an edge intelligent execution unit, and a terminal device unit connected in sequence; wherein,

[0027] The cloud-based intelligent management and control unit is used for semantic abstraction of heterogeneous devices, global policy orchestration, device lifecycle management, and intelligent operation and maintenance analysis.

[0028] The secure communication network unit is used to provide a secure and reliable data transmission channel between the cloud, the edge, and terminal devices;

[0029] The edge intelligent execution unit is deployed in various control areas, integrating an edge computing framework, a rule engine, and a layered architecture of edge core services, and is responsible for protocol conversion, collaborative scheduling, and local autonomous execution;

[0030] The terminal equipment unit includes heterogeneous landscape lighting equipment and Internet of Things (IoT) terminal equipment from multiple brands and protocols.

[0031] In a possible preferred embodiment, the cloud-based intelligent management and control unit includes:

[0032] Device Capability Library: Stores a unified abstract model of device capabilities and capability point templates, matches the corresponding capability model according to the parameters of the access device, generates and manages digital twins of devices, and provides standardized application programming interfaces;

[0033] The strategy orchestration module provides a strategy orchestration interface, completes scenario strategy orchestration based on the standardized application programming interface of the digital twin, and compiles and distributes the strategies to the edge.

[0034] Data intelligence analysis module: It gathers system-wide operational data, environmental data, and operation logs for data processing and mining analysis.

[0035] In a possible preferred embodiment, the terminal equipment unit includes at least one of the following: a low-voltage main control / sub-control device, a high-voltage control unit, various landscape lighting execution devices, environmental sensing devices, and a supporting control system.

[0036] To achieve the above objectives, according to another aspect of the present invention, a computer-readable storage medium is also provided, on which a computer program is stored, wherein when the computer program is executed by a processor, it implements the unified management and control method for heterogeneous landscape lighting devices as described in any of the preceding claims.

[0037] The unified management and control method, system, and storage medium for heterogeneous landscape lighting devices provided by this invention cleverly decouple device functions from underlying communication protocols by designing and utilizing a unified device capability abstraction model in the cloud. Combined with a hot-swappable driver plug-in architecture on the edge side, existing devices can be quickly connected to IoT terminals without modification or replacement. This is achieved simply by developing or configuring corresponding driver plug-ins, fundamentally solving the problems of fragmented device protocols and "information silos" in the landscape lighting field, and greatly improving the openness and ecological inclusiveness of the system. Attached Figure Description

[0038] The accompanying drawings, which form part of this application, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings:

[0039] Figure 1 This is a schematic diagram illustrating the steps of the unified management and control method for heterogeneous landscape lighting devices according to the present invention.

[0040] Figure 2 This is a schematic diagram of the cloud-edge-end three-layer architecture of the unified management and control system for heterogeneous landscape lighting devices of the present invention.

[0041] Figure 3 This is a schematic diagram of the network connection relationship of the heterogeneous landscape lighting equipment in the unified management and control system of the present invention;

[0042] Figure 4 A schematic diagram of device protocol interoperability in the unified management and control system for heterogeneous landscape lighting devices of the present invention;

[0043] Figure 5 A schematic diagram of clock calibration in the unified management and control system for heterogeneous landscape lighting equipment of the present invention;

[0044] Figure 6 This is a schematic diagram of the capability model abstraction process in the unified management and control system for heterogeneous landscape lighting equipment of the present invention.

[0045] Figure 7 This is a schematic diagram of the cloud-edge-device collaboration process in the unified management and control system for heterogeneous landscape lighting devices of the present invention. Detailed Implementation

[0046] To enable those skilled in the art to better understand the technical solutions of the present invention, the specific technical solutions of the present invention will be clearly and completely described below in conjunction with embodiments, so as to help those skilled in the art further understand the present invention. Obviously, the embodiments described in this application are merely some embodiments of the present invention, and not all embodiments. It should be noted that, for those skilled in the art, the embodiments and features in the embodiments of this application can be combined with each other without departing from the concept of the present invention and without conflict. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the disclosure and protection scope of the present invention.

[0047] Furthermore, the terms "first," "second," "S100," "S200," etc., used in the specification, claims, and drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such features can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in a sequence other than those described herein. At the same time, the stages described in each step are not necessarily to be implemented in the same step; it should be understood that the implementation order of the contents of each step stage can be adjusted and interchanged without violating the inventive concept, so that the step embodiments of the invention described herein can be implemented in a sequence other than those described herein. Additionally, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. Unless otherwise expressly specified and limited, the terms "set," "arrange," "install," "connect," and "link" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; a mechanical connection or an electrical connection; a direct connection or an indirect connection through an intermediate medium; or a connection within two elements. Those skilled in the art can understand the specific meaning of the above terms in this case based on the specific circumstances and existing technology.

[0048] To address the fundamental technical challenge of centralized management and high-precision synchronization of lighting control equipment across multiple parks, brands, and heterogeneous structures, such as... Figure 1 As shown, this invention provides a method for unified management and control of heterogeneous landscape lighting devices, the steps of which include:

[0049] Step S100: Abstract the functional units of heterogeneous devices into standardized capability points, complete the semantic definition of devices, and construct a unified device capability abstract model.

[0050] Specifically, for large-scale, multi-park light show projects, there may be more than 10 parks involved, each containing dozens of buildings and various types of lighting control equipment. Therefore, to form a cluster management system, an edge server can be deployed in each park. This edge server acts as the "local administrator" of the park, responsible for controlling all third-party lighting control equipment within the park that can achieve network interconnection.

[0051] Meanwhile, these edge servers distributed across multiple parks will be connected to the cloud, enabling centralized management of multiple parks through a single cloud platform. This will achieve many-to-many control, with one cloud platform controlling multiple edge servers and one edge server controlling multiple lighting terminals within its park.

[0052] However, building a system architecture that achieves three-layer collaboration between cloud, edge, and device is not simply a matter of adding up functions. It requires addressing the specific and complex scenario of centralized control of multiple parks, multiple brands, and heterogeneous devices.

[0053] Therefore, the present invention is conceived as follows: Figure 2 As shown, this paper attempts to design a novel "cloud-edge-device" three-layer collaborative landscape lighting control architecture. By introducing a unified device abstract model in the cloud, it completely solves the problems of difficult access to heterogeneous devices and complex protocol conversion, realizing "Internet of Everything and plug-and-play". It incorporates various protocols (such as HTTP, DMX, MQTT, RS485, CAN, etc.) in heterogeneous devices into the device capability library in the cloud, and unifies the device capabilities of heterogeneous devices into a unified file to distribute scene linkage performance.

[0054] Specifically, this device capability library is essentially an extensible function repository. It doesn't directly describe the "device," but rather abstracts various controllable and observable atomic functions (called "capability points") of the device. For example, "switch control," "brightness adjustment," and "current query" are all independent capability points. These capabilities, after being standardized and defined, can be reused on different projects and different models of devices. A physical device (such as a multi-functional controller) can be mapped to multiple such atomic capability points in the cloud, thereby enabling flexible combination and reuse of functions.

[0055] For example, first define a unified device capability abstract model, referring to... Figure 6 As shown, the smallest functional unit of a device that can be controlled or observed is abstracted into structured capability points. Each capability point includes a semantic identity module, a communication protocol and instruction template module, a call interface mapping module, an expected feedback parsing rule module, and an interaction interface contract module.

[0056] The semantic identity module is used to store globally unique capability IDs, business-oriented capability names, device IP addresses, and port information.

[0057] The communication protocol and instruction template module specifies the underlying communication protocol (such as RS485, RS232, MQTT, DMX512, ArtNet, Modbus, CAN, etc.) that implements this capability, and provides parameterized instruction message templates, while declaring the corresponding physical parameters. For example, the template might be {device_address}{function_code}{register_address}{length}, where device_address, etc., are the parameters to be filled. The protocol carrier declares one or more underlying communication protocols that can be mapped to implement this semantic function, as well as the necessary physical parameters (such as register address, DMX channel number).

[0058] The API mapping module is used to specify the specific service interface to be called on the edge side when this capability is executed, corresponding to a certain API in the SysManager system layer (e.g., SysManager.GetInfo() for collecting current transformer data).

[0059] The expected feedback parsing rule module is used to define the parsing rules for the original message returned by the device, and to convert the original byte stream (such as 0x01 0x03 0x04 0x00 0x00 0x13 0x8A...) into standardized service data (such as {"voltage":220.5,"current":10.2}).

[0060] The interactive interface contract module is used to define the data structure, type, and value range of standardized input and output parameters for calling this capability.

[0061] Based on the capability point template, the cloud platform instantiates each capability into a remotely invoked general-purpose execution function. When the function is invoked, it automatically completes the entire process of parameter filling, protocol assembly, interface calling, and data parsing.

[0062] Step S200: Build a cloud-edge collaborative edge computing architecture. Based on the unified device capability abstract model, perform model matching and dynamic instantiation of the access devices to generate device digital twins and compile twin instructions that can call the standardized application programming interface of the digital twins in a standardized manner.

[0063] Specifically, the process of building an edge computing architecture that integrates cloud and edge computing includes:

[0064] Step S201: Build the edge computing framework and rule engine.

[0065] The edge computing architecture described above uses EdgeXFoundry as its core, and the edge computing middleware is deployed using Docker containers to manage device services in a unified manner. eKuiper, as a lightweight streaming engine, is integrated with EdgeXFoundry to execute real-time data processing rules at the edge.

[0066] The specific implementation of the eKuiper rules includes: cloud-orchestrated scenario strategies are instantiated into one or more eKuiperSQL rules at the edge. Each rule contains a data source (e.g., subscribing to EdgeX device event streams), processing logic (SQL statements, which can perform filtering, aggregation, and call AI inference functions such as tfLite), and data output (e.g., calling local service interfaces or reporting to the cloud). The rule engine supports both timed and event-triggered triggers and can be configured with an automatic restart strategy for failures, ensuring the reliability of edge autonomous execution.

[0067] The integration of eKuiper and EdgeXFoundry allows for direct processing of data collected from devices at the edge, reducing reliance on the cloud. Integration methods include: Data access: eKuiper can subscribe to data streams from the CoreData service via EdgeXFoundry's ZeroMQ interface; Data output: Processed results can be sent to MQTT brokers, HTTP endpoints, or other targets, enabling edge-to-cloud collaboration. This integration is suitable for scenarios such as Industrial IoT and smart cities, enabling real-time data analysis, improving system response speed, and saving bandwidth.

[0068] Step S202: Construct a three-layer mapping and transformation architecture for edge core services.

[0069] The edge core service architecture, from bottom to top, includes a device protocol adaptation layer, a lighting control abstraction layer, and an edge service management layer.

[0070] The SensorDevice layer acts as a unified protocol adapter executor. Its core is a hot-plugging device driver plugin management framework. It uses ping to detect the online status of connected devices' heartbeats and issues offline alarms, reporting to the cloud via MQTT. Each driver plugin exists as an independent container or dynamic link library, adhering to a unified interface specification and requiring the implementation of the `pack()` and `unpack()` methods. The `pack()` method receives standardized JSON / HEX commands and device context information, generating HEX command frames conforming to the target device's specifications through internal mapping logic. The `unpack()` method extracts and transforms valid data from the raw response byte stream according to predefined parsing rules. The framework provides plugin lifecycle management, dependency injection, and a secure sandbox environment.

[0071] The SubControl layer, acting as an interpreter and forwarder of high-level lighting commands, encapsulates the core engine of professional lighting control software (such as QLC+) through containerization, providing a set of RESTful APIs. Its core responsibility is protocol abstraction; for example, translating the API call to "play scene A" into a call to an internal function of the underlying QLC+ engine (such as starting a specific Chaser or Collection), which is then used by the QLC+ engine to generate continuous DMX512 or sACN (E1.31) data streams in real time. This layer separates artistic creativity from the underlying hardware protocol.

[0072] The edge service management layer (SysManager) acts as a resource management and system service agent for the edge hardware itself. It is a core orchestrator running as a daemon. It integrates several key services: a high-availability clock synchronization service, supporting multi-source redundancy (NTP / PTP / GPS) and hierarchical time synchronization; a resource telemetry service, which periodically collects hardware metrics by reading system files (such as / proc) and calling performance interfaces; a secure file transfer service, which achieves reliable synchronization and version management of files with the cloud based on SSH / SFTP protocols; and a system control plane, which provides remote configuration, service discovery, process health checks, and self-healing for the edge hardware.

[0073] Specifically, the device model matching and dynamic instantiation process in step S200 includes:

[0074] Model instantiation and dual-track binding: When a physical device is connected, the system performs a crucial dual-track binding, namely:

[0075] Semantic binding: In the cloud, based on the device model, a set of "capability points" are matched and instantiated from a predefined model library to generate a digital twin of the device. This twin only exposes standardized APIs based on semantics (e.g., 1: Lighting device recommendation, turn on water curtain, turn on fog, turn off fountain, turn on floodlight to play program 1; e.g., 2: IoT device recommendation, collect data, execute commands, etc.).

[0076] Protocol binding: On the edge side, one or more driver plugins are configured synchronously for each "capability point". This plugin encapsulates all the logic for converting standardized parameters into device-specific native command frames (such as Modbus messages and Art-Net packets), and is responsible for connection maintenance and data parsing.

[0077] Edge Discovery and Reporting: After the modular edge devices deployed on-site are started, their system service layer (SysManager) is used by operations and maintenance personnel to perform device discovery, collect the unique device code (model, address, etc.), and report it to the cloud via the MQTT protocol.

[0078] Cloud-based model matching and instantiation: After receiving information, the cloud queries the capability model library for matching. The system combines the abstract device ID with specific device communication parameters (such as Modbus slave address and IP address) to instantiate and generate a device-specific "device configuration list". This list fully describes "what the device can do (semantics)" and "how to do it (protocol and parameters)".

[0079] Edge driver injection and readiness: The cloud distributes the "device configuration list". The edge gateway's device protocol adaptation layer (SensorDevice) dynamically loads the corresponding driver plugin based on the EdgeBinding information in the list, and injects the specific communication parameters into the plugin instance, thus completing the protocol driver readiness.

[0080] Specifically, the process of generating digital twins and standardized APIs through cloud-edge collaboration in step S200 includes:

[0081] Visual strategy orchestration and logical decomposition based on digital twin API.

[0082] In the cloud-based strategy designer, operators directly manipulate the semantic APIs provided by the digital twin for graphical orchestration (such as dragging and dropping "Building A's brightness" and "Square B's playback scene" to link them). The orchestration engine compiles the graphical logic into an intermediate representation called a "twin instruction sequence." This sequence consists of a series of calls to specific twin APIs, specifying "what to do" and "to whom," but still not including the specific details of "how to implement it through the protocol."

[0083] Accurate protocol conversion and distribution are achieved through an edge collaborative execution engine.

[0084] This step represents a crucial shift from "what to do" to "how to do it," and is the core of ensuring real-time control and synchronization accuracy.

[0085] Command reception and task scheduling: The cloud sends the "twin command sequence" to the target edge gateway. The edge stream processing rule engine integrated within the gateway receives the commands and converts them into a localized execution task graph.

[0086] Deterministic collaborative execution: The rules engine acts as a local scheduling hub, scheduling edge service layer resources in parallel or sequentially based on the timing and dependencies of the task graph. For example, at precisely the same timestamp, it can simultaneously invoke the "relay closure" plugin in the SensorDevice layer and the "lighting scene playback" service in the SubControl layer.

[0087] The final protocol conversion and output: The called driver plugin (in the SensorDevice layer) or service (in the SubControl layer) executes the specific pack() or rendering logic based on the parameters injected during instantiation, generating the final Modbus TCP, DMX512, or Art-Net protocol messages, which are then sent through the physical interface to drive the device. The entire execution process is closed-loop at the edge, unaffected by cloud network latency, ensuring microsecond-level synchronization accuracy.

[0088] Once instantiation is complete, the cloud creates a digital twin of the physical device. This twin is essentially a set of standardized RESTful APIs that are bound to all the device's capabilities and can be invoked instantly. For example, for the DimmerControl capability, the PUT / api / twins / {deviceId} / brightness interface is automatically generated. From then on, any upper-layer system can interact with the device through these semantic APIs without needing to be aware of its physical protocol.

[0089] Intelligent operation and maintenance based on unified data flow.

[0090] All device status and energy consumption data are parsed by the driver plugin's unpack() function, forming a unified data stream that is then reported to the cloud. Based on this complete data, the platform can perform real-time monitoring, energy efficiency analysis, and predictive maintenance. For example, it can analyze current harmonic trends using machine learning models and generate maintenance work orders in advance.

[0091] Step S300: Perform edge-to-edge collaborative control, complete the conversion of twin commands to the device's native protocol through the edge side, and execute the pre-stored lighting control commands in real time based on the edge side's local computing and caching capabilities.

[0092] Specifically, this step is the core of achieving precise implementation of cloud-based policies in the physical world. It describes the collaborative workflow between the edge intelligent gateway and its managed terminal devices, ensuring that unified, abstracted control commands are reliably, efficiently, and accurately translated into native device actions. This process is a complete closed loop encompassing device discovery, protocol-driven execution, command execution, and status feedback, and includes the following example sub-steps:

[0093] Step S301 Device discovery, connection and status management.

[0094] Once the edge smart gateway is started, its system service layer automatically performs device discovery and connection management.

[0095] Active discovery and registration: The gateway actively discovers terminal devices within its network or physical interface range by polling pre-configured IP address ranges, scanning fieldbuses, or receiving ad hoc network broadcasts from devices. After discovering a device, it collects its basic identification information.

[0096] Connection maintenance and heartbeat monitoring: For devices requiring sustained sessions, the gateway establishes and maintains stable physical and data link layer connections. Simultaneously, the system service layer periodically sends heartbeat (ping) messages to all managed devices to continuously monitor their online status. Any connection interruption or heartbeat timeout event is recorded in real time and proactively reported to the cloud platform via protocols such as MQTT, triggering device offline alarms.

[0097] Step S302: Protocol driver loading and instruction adaptation and conversion.

[0098] When the twin command issued from the cloud reaches the edge gateway, the edge rule engine schedules the device protocol adaptation layer to perform specific protocol conversion based on the device identifier and capability model ID specified in the command.

[0099] Driver plugin invocation: The device protocol adaptation layer locates and invokes the corresponding device driver plugin based on the pre-defined binding relationships. This plugin encapsulates all the communication details of a specific device or protocol family.

[0100] The "Compile" command triggers the core `pack()` method of the driver plugin. This method receives standardized JSON command parameters, which, combined with device configuration information, execute the following logic:

[0101] Parameter mapping: Mapping business parameters to protocol-specific fields;

[0102] Frame structure assembly: According to the protocol specification, fill in the start bit, device address, function code, data field, check code, etc., and assemble into a complete binary instruction frame;

[0103] Physical interface adaptation: The generated instruction frame is sent through the corresponding physical interface.

[0104] Step S303 Multi-device collaboration and high-precision timing scheduling.

[0105] For complex scenarios involving multiple devices that need to execute synchronously, the edge side assumes the responsibility of high-precision timing scheduling.

[0106] Local timing planning: When parsing the sequence of instructions issued from the cloud, the edge rule engine will identify the timestamps and synchronization requirements, and generate a local microsecond-level execution schedule based on the local high-precision clock of the edge gateway.

[0107] Parallel Triggering and Execution: At preset precise time points, the rule engine triggers multiple driver plugin calls for different devices in parallel. Since all scheduling and protocol conversions are completed locally at the edge, network latency jitter from the cloud to the edge is completely avoided. For example, the local scheduler at the edge (such as within the gateway) considers the timing requirements of instructions and device response characteristics, performing scheduling and distribution with microsecond-level precision. For light show instructions with strong real-time requirements, the gateway can utilize its local computing and caching capabilities to directly play pre-stored instruction sequences, ensuring frame synchronization without stuttering. All instruction execution results and status changes are collected by the gateway in real time and fed back to the cloud. This ensures sub-millisecond synchronization accuracy for cross-device actions, meeting the stringent requirements of large-scale coordinated light shows and other demanding scenarios.

[0108] In addition, in optional embodiments, it may also include:

[0109] Step S304 executes feedback and status data acquisition.

[0110] After the device executes the command, the edge gateway collects the execution results in real time to complete the control closed loop, which specifically includes:

[0111] Response parsing: The raw response data returned by the device is processed by the corresponding driver plugin's `unpack()` method in the device protocol adaptation layer. This method extracts valid data from the raw byte stream according to predefined parsing rules and converts it into standardized JSON format status information.

[0112] Data reporting and digital twin synchronization: The parsed device status data is immediately published to the edge local message bus. On the one hand, the edge rules engine can process it in real time; on the other hand, the status data is reported to the cloud through a reliable channel to update the real-time status attributes of the corresponding digital twin, ensuring the consistency between the cloud virtual model and the physical world state, and providing an accurate data foundation for monitoring, analysis, and intelligent operation and maintenance.

[0113] On the other hand, corresponding to the above methods, such as Figure 2As shown, the present invention also provides a unified management and control system for heterogeneous landscape lighting equipment, an example of which includes: a cloud-based intelligent management and control unit, a secure communication network unit, an edge intelligent execution unit, and a terminal device unit that are connected in sequence.

[0114] Specifically, the cloud-based intelligent management and control unit is used for semantic abstraction of heterogeneous devices, global policy orchestration, full lifecycle management of devices, and intelligent operation and maintenance analysis; the secure communication network unit is used to provide a secure and reliable data transmission channel between the cloud, edge, and terminal devices; the edge intelligent execution unit, such as an edge server, is deployed in various management and control areas, integrating an edge computing framework, rule engine, and edge core service layered architecture, and is responsible for protocol conversion, collaborative scheduling, and local autonomous execution; the terminal device unit includes heterogeneous landscape lighting equipment and IoT terminal devices from multiple brands and protocols.

[0115] The cloud-based intelligent management and control unit includes:

[0116] Device Capability Library: It is used to store a unified abstract model of device capabilities and capability point templates, match the corresponding capability model according to the parameters of the access device, generate and manage digital twins of devices, and provide standardized application programming interfaces.

[0117] Policy orchestration module: Provides a policy orchestration interface, completes scenario policy orchestration based on the standardized application programming interface of digital twin, and distributes the compiled policies to the edge.

[0118] Data intelligence analysis module: used for performance execution detection, it performs data processing and mining analysis by aggregating the system's operational data, environmental data and operation logs.

[0119] The terminal equipment unit specifically includes at least one of the following: low-voltage main control / sub-control equipment, high-voltage control unit, various landscape lighting execution equipment, environmental sensing equipment, and supporting control system.

[0120] For example, such as Figure 3 As shown, when deploying the system of this invention, an edge server can be deployed in each park. This edge server acts as the "local administrator" of the park, responsible for controlling all third-party lighting control devices in the park that can achieve network interconnection. The example of the cloud-based intelligent management and control unit takes the setup of a cloud-based central server as an example, which is networked with the edge servers deployed in each park via 4G / WIFI / wired, etc.

[0121] The edge server communicates with third-party lighting main controllers and sub-controllers via a local area network, and connects with IoT devices such as power control boxes and sensors via a network or RS485.

[0122] like Figure 4As shown, the cloud distributes planned tasks to the target edge server via MQTT publish / subscribe protocol. The task scheduler integrated within the edge server receives the instructions and parses them into a local execution task queue. As the local task scheduling hub, it schedules functions of various service layers on the edge server in parallel or serially according to the timing and dependencies of the task queues.

[0123] like Figure 5 As shown, the edge server performs high-precision clock calibration via manual synchronization using cloud MQTT or automatic execution via an NTP scheduled task. The NTP scheduled task can be started and stopped via the cloud. The example provides three methods for calibrating the edge server system time: network API time calibration, satellite calibration to obtain 4G module time calibration, and cloud server time calibration. It can detect whether the system time of multiple edge servers is synchronized and allows for manual one-click calibration.

[0124] Currently, common centralized lighting control methods on the market typically involve a scheduled task executed on a cloud server to obtain the server system time and control lighting devices of the same brand. This solution has limitations; it does not support third-party brands and cannot meet the needs of large-scale synchronized performances. Each lighting controller receives instructions at different times, and due to network latency, the time differences between devices become increasingly significant, often requiring a restart after 10 minutes or more to achieve synchronized operation.

[0125] The clock calibration method using an edge server deployed on-site, as described in this invention, offers a significant advantage in clock accuracy compared to the aforementioned time control methods. Local area network communication between the edge server and third-party lighting control devices avoids the impact of internet latency by employing NTP for automatic network time calibration of the edge server's system time every minute. When parsing the instruction queue issued from the cloud, the edge server's task scheduler identifies the timestamps and generates a local microsecond-level execution schedule based on the edge server's local high-precision clock. At preset precise time points, the rule engine triggers multiple function calls for different devices in parallel.

[0126] Since all scheduling and protocol conversions are completed locally on the edge server, network latency jitter from the cloud server to the edge server is completely avoided, thus ensuring millisecond-level synchronization accuracy of cross-device actions and meeting the demanding requirements of scenarios such as large-scale coordinated light shows.

[0127] For example, and such Figure 6As shown, the system designed in this invention includes a unified management platform deployed in the cloud, edge servers deployed in each park, and various third-party lighting control devices from different manufacturers within each park, supporting multiple protocols (such as DMX512, Art-Net, TCP, UDP, RS485, etc.). Furthermore, during the device access and model building phase, when a third-party lighting control device accesses the cloud, the cloud sends basic information about the device, including device ID, IP address, port, communication protocol, and control command set, to the corresponding park's edge server via the MQTT protocol. To ensure accurate execution of orchestrated commands, each "capability function" in the cloud-based device capability library is pre-bound to a specific calling interface on the edge server. This binding relationship is established during device access and capability model building.

[0128] Suppose that the cloud-based scene strategy orchestration generated seven large-scale collaborative performance instructions for different park holiday modes:

[0129] At 6 PM, the power lights in zones A, B, C, D, E, F, and G will be switched on (RS485 power control box).

[0130] At 6:10 p.m., all parks will execute the low-voltage electrical performance program 1 (third-party lighting control).

[0131] At 7 p.m., a laser light show will be performed in Zones A, B, and C (with third-party lighting control).

[0132] At 7:10 PM, all parks will execute the low-voltage electrical performance program 2 (third-party lighting control).

[0133] At 7 p.m., a beam light show will be performed in zones D, E, F, and G (with third-party lighting control).

[0134] At 8 p.m., all power to the park was shut off.

[0135] At this point, the edge server task scheduling execution logic "power light on" capability is bound to the general protocol function interface RS485 (target ID, IP, power on command) of the device capability execution layer, while the "low voltage performance on" capability is bound to the general protocol function interface UDP (target ID, IP, power on command) of the device capability execution layer. Multi-channel lighting control such as "laser light, beam light performance on" is bound to the lighting control layer by the call of internal functions of the QLC+ engine, and then the QLC+ engine generates a continuous DMX512 data stream in real time (target light sub-control ID or IP, DXM512 data stream).

[0136] The resulting "cloud-edge-device" collaborative execution chain ensures that commands issued from the cloud can be accurately executed by the corresponding terminal devices through the edge servers. When a device is connected, the capabilities of the connected devices in the cloud device capability model can be reused. For a brand-new device, its smallest controllable functional unit (such as "switch control") can be abstracted into a device capability. A physical device can be mapped to multiple device capabilities in the cloud, thereby providing flexible data combination support for scene orchestration.

[0137] When orchestrating scene strategies in the cloud, the designers are scheduling these virtualized "device capability functions". During the orchestration process, the general protocol functions of the edge server (such as executing the TCP protocol) are bound to the characteristic parameters of the target third-party lighting control device (such as ID, IP, control commands, etc.).

[0138] A complex lighting performance scene is essentially composed of multiple cross-device "capability functions" arranged and combined according to timelines and logical conditions. After the cloud distributes the scene performance plan task, the edge server receives the task and saves it to the rule engine (eKuiper), scheduling the task according to a preset time sequence. When a task is triggered, the edge server calls the corresponding generic method (such as UDP, TCP connection, or DMX protocol encapsulation) based on the protocol used by the target device, using the control commands and target device ID carried in the task as key parameters. The edge server first searches its locally synchronized device basic information database to obtain the target device's real-time IP, port, and protocol details, effectively reducing network requests and latency during execution. Subsequently, the edge server sends the specific control commands directly to the target third-party lighting control device via the campus LAN.

[0139] The communication and command execution process between the third-party lighting control device and the system is as follows: The third-party lighting control device, as a controlled node, connects to the park's local area network. When the edge server's rule engine (eKuiper) triggers a task according to the scheduling plan, the edge server, as the control end, actively initiates communication with the target third-party lighting control device. The process is as follows: First, the server looks up the device's basic information (including IP, port, and protocol type) in its local storage based on the device ID in the task parameters; then, based on its protocol type, it calls the corresponding communication method to actively initiate a connection or send command messages. For example, for TCP protocol devices, the edge server will actively create a Socket connection to the device's IP and port; for connectionless protocols such as UDP or Art-Net, it will directly send encapsulated data packets to the target address and port.

[0140] The command message is generated based on the "capability" parameters issued from the cloud and the locally bound protocol interface. After receiving the message, the communication module on the third-party device extracts the valid control command and executes it.

[0141] Furthermore, to establish a reliable control loop, the edge server can confirm the execution result in two ways after sending the command: First, for protocols that support status feedback, the server can proactively send a query message to request the device to return the current status or confirm the command execution; second, after execution, the device can also proactively send a status feedback message to the port specified by the edge server, as agreed in the protocol. The edge server receives and parses this feedback, and notifies the cloud of the execution result via MQTT, thereby ensuring the accurate and reliable execution of the cloud's orchestration intent and its visible status.

[0142] like Figure 7 As shown, the collaborative process between the cloud, edge servers, and third-party lighting control terminals is illustrated: the cloud combines the capabilities of each device to create a scene performance program, the cloud notifies the task scheduling rules deployed on the edge server via the MQTT protocol, and the edge terminal parses and stores the received performance instruction control set into the rule engine in sequence.

[0143] Task scheduling is based on the control commands from third-party lighting control devices, either serially or in parallel, according to the trigger time. Specifically, the edge server calls different generic methods (such as UDP methods) based on the protocol of the third-party lighting control device, and sends the control commands stored in the rule engine as parameters to the target third-party lighting control device for execution.

[0144] The cloud-based performance file is distributed via MQTT notification to the edge server's operating system layer. The operating system layer then retrieves the downloaded file from the cloud server, preventing transmission interruptions due to network jitter. The edge server then sends the file to a third-party lighting control terminal via SFTP.

[0145] Edge server data acquisition tools are used for control command execution feedback and status data collection. After the device executes a command, the edge server collects the execution results in real time and notifies the cloud to complete the control loop. The cloud then automatically analyzes the collected performance data to determine whether to initiate alarm processing.

[0146] The edge server connects to third-party lighting control devices for status management. After startup, the edge server's operating system layer automatically performs device discovery and connection management by polling pre-configured IP address ranges. Upon device discovery, it establishes and maintains heartbeat monitoring: for devices requiring a persistent session, the gateway establishes and maintains stable physical and data link layer connections. Simultaneously, the operating system layer periodically sends heartbeat (ping) messages to all managed devices to continuously monitor their online status. Any connection interruption or heartbeat timeout event is recorded in real time and proactively reported to the cloud platform via protocols such as MQTT, triggering device offline alarms.

[0147] The edge server task scheduling layer, in this example, uses the eKuiper rule engine as the "general scheduler" on the edge side. It is responsible for automatically executing complex task sequences according to plans and conditions, realizing automatic intelligent scheduling of edge servers. Its core is the three-layer service architecture collaborative scheduling and local autonomous execution.

[0148] As can be seen from the above embodiments, the system and method provided by the present invention not only achieve unified, stable and efficient control of ultra-large-scale, extremely heterogeneous landscape lighting systems, but also elevate operation and maintenance to a new level through data intelligence, fully meeting the core requirements of modern smart cities for the digitalization, networking and intelligence of important urban infrastructure.

[0149] On the other hand, in accordance with the above method, the present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, it implements the unified management and control method for heterogeneous landscape lighting devices as described in any of the preceding claims.

[0150] In summary, the unified management and control method, system, and storage medium for heterogeneous landscape lighting devices provided by this invention cleverly decouple device functions from underlying communication protocols by designing and utilizing a unified device capability abstraction model in the cloud. Combined with a hot-swappable driver plug-in architecture on the edge side, existing devices can be quickly connected to IoT terminals without modification or replacement. This is achieved simply by developing or configuring corresponding driver plug-ins, fundamentally solving the problems of fragmented device protocols and "information silos" in the landscape lighting field, and greatly improving the openness and ecological inclusiveness of the system.

[0151] Furthermore, in the corresponding implementation, firstly, the present invention constructs a three-layer collaborative architecture of cloud, edge, and terminal, which significantly improves system stability and control accuracy. For example, by deploying edge intelligent servers in various parks, an architecture of "centralized cloud management and local edge execution" is formed, which pushes the logic of protocol conversion, timing scheduling, and instruction execution down to the edge side, completely avoiding network latency and jitter issues in point-to-point communication between the cloud and the terminal, achieving sub-millisecond synchronization accuracy for cross-device actions, and meeting the stringent timing requirements of large-scale interactive light shows; at the same time, the edge side can achieve offline autonomous execution, avoiding device loss of control and single-point failure propagation caused by public network link fluctuations, and significantly improving the overall reliability of the system.

[0152] Secondly, this invention replaces the point-to-point communication between the cloud and a large number of terminals in the traditional solution with one-to-many communication between the cloud and the edge. The cloud only needs to maintain the communication link with the edge server, and the number of connections and resource consumption are reduced by orders of magnitude. Large performance files and unified instructions only need to be sent to the edge server, and then distributed to local terminals by the edge server, which greatly reduces the use of public network bandwidth and improves data distribution efficiency. At the same time, the system can achieve elastic expansion of the number of access parks and devices by adding edge servers to adapt to the needs of projects of different sizes.

[0153] Third, by using digital twins of equipment and standardized semantic APIs, the complex underlying protocol logic is completely encapsulated. Lighting designers and operators do not need to understand the equipment brand or protocol details. They can independently complete the creation and deployment of cross-park and cross-device linkage scenes through cloud-based visual orchestration tools, which greatly shortens the creative realization cycle and improves the upper limit of landscape lighting art expression and operational flexibility.

[0154] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention. The invention is limited only by the claims and their full scope and equivalents. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the invention should be included within the scope of protection of the invention.

[0155] Those skilled in the art will understand that, besides implementing the system, apparatus, unit, and its modules provided by this invention in purely computer-readable program code, the same program can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, the system, apparatus, and its modules provided by this invention can be considered as a hardware component, and the modules included therein for implementing various programs can also be considered as structures within the hardware component; alternatively, the modules for implementing various functions can be considered as both software programs implementing the method and structures within the hardware component.

[0156] Furthermore, all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a microcontroller, chip, or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0157] Furthermore, various different implementations of the present invention can be combined arbitrarily, as long as they do not violate the spirit of the present invention, they should also be regarded as the content disclosed in the present invention.

Claims

1. A method for unified management and control of heterogeneous landscape lighting equipment, comprising the following steps: Step S100: Abstract the functional units of heterogeneous devices into standardized capability points, complete the semantic definition of devices, and build a unified device capability abstraction model; Step S200: Build a cloud-edge collaborative edge computing architecture. Based on the unified device capability abstract model, perform model matching and dynamic instantiation of the access devices to generate device digital twins and compile twin instructions that can call the standardized application programming interface of the digital twins in a standardized manner. Step S300: Perform edge-to-edge collaborative control, complete the conversion of twin commands to the device's native protocol through the edge side, and execute the pre-stored lighting control commands in real time based on the edge side's local computing and caching capabilities.

2. The method according to claim 1, wherein the step S100 of abstracting the functional units of heterogeneous devices into standardized capability points includes: Define a semantic identity module to store globally unique capability IDs, business-oriented capability names, and device IP addresses and port information; Define the communication protocol and instruction template module, specify the underlying communication protocol corresponding to the implemented capability, provide parameterized instruction message templates and declare the corresponding physical parameters; Define the API mapping module to specify the specific service interfaces that the edge side needs to call when executing capabilities; Define the expected feedback parsing rules module, set the parsing rules for the device's original return messages, and realize the conversion of the original byte stream into standardized business data; Define the interaction interface contract module, and set the data structure, type, and value range of the standardized input and output parameters for calling capabilities.

3. The method according to claim 1, wherein the step of building a cloud-edge collaborative edge computing architecture in step S200 includes: By containerizing edge computing middleware and rule engine deployment, a three-layer architecture is constructed, consisting of a device protocol adaptation layer, a lighting control abstraction layer, and an edge service management layer. This architecture enables model matching and dynamic instantiation of access devices to achieve dual-track binding of semantic and protocol binding. Furthermore, based on cloud-edge collaboration, digital twins of devices and standardized application programming interfaces are generated, supporting visualized scene policy orchestration and collaborative execution.

4. The method according to claim 3, wherein, The device protocol adaptation layer is a hot-swappable driver plugin management framework that enables bidirectional conversion between standardized commands and device native protocols. The lighting control abstraction layer encapsulates the lighting control core engine in a containerized manner and provides standardized application programming interfaces to complete the conversion of standardized control commands. The edge service management layer runs as a daemon process, integrates various basic services, and is responsible for edge system management and service scheduling.

5. The method according to claim 3, wherein the dual-track binding step comprises: After the edge device starts up, it performs device discovery, collects the unique device coding information, and reports it to the cloud platform via the MQTT protocol. The cloud platform queries the device capability model library to complete the matching, instantiates and generates a device-specific configuration list, and distributes it. The edge device loads the corresponding driver plugin and injects device communication parameters according to the configuration list, thus completing the protocol driver readiness.

6. The method according to claim 3, wherein the steps of generating a digital twin of a device and a standardized application programming interface based on cloud-edge collaboration, and completing the visualization scene strategy orchestration and collaborative execution include: After the device is instantiated, the cloud platform creates a digital twin of the physical device in the form of a standardized application programming interface (API) that is bound to all capability points. Based on this standardized API, the platform completes the orchestration of visual scenario strategies and compiles them into a twin instruction sequence. After being sent to the edge, the rule engine converts it into a local execution task graph and schedules the edge core service resources according to the time sequence and dependencies, thus completing the protocol conversion and instruction execution in a closed loop.

7. A unified management and control system for heterogeneous landscape lighting equipment, used to perform the method as described in any one of claims 1-6, comprising: The cloud-based intelligent control unit, secure communication network unit, edge intelligent execution unit, and terminal device unit are sequentially connected via communication; among them... The cloud-based intelligent management and control unit is used for semantic abstraction of heterogeneous devices, global policy orchestration, device lifecycle management, and intelligent operation and maintenance analysis. The secure communication network unit is used to provide a secure and reliable data transmission channel between the cloud, the edge, and terminal devices; The edge intelligent execution unit is deployed in various control areas, integrating an edge computing framework, a rule engine, and a layered architecture of edge core services, and is responsible for protocol conversion, collaborative scheduling, and local autonomous execution; The terminal equipment unit includes heterogeneous landscape lighting equipment and Internet of Things (IoT) terminal equipment from multiple brands and protocols.

8. The system according to claim 7, wherein the cloud-based intelligent management and control unit comprises: Device Capability Library: Stores a unified abstract model of device capabilities and capability point templates, matches the corresponding capability model according to the parameters of the access device, generates and manages digital twins of devices, and provides standardized application programming interfaces; The strategy orchestration module provides a strategy orchestration interface, completes scenario strategy orchestration based on the standardized application programming interface of the digital twin, and compiles and distributes the strategies to the edge. Data intelligence analysis module: It gathers system-wide operational data, environmental data, and operation logs for data processing and mining analysis.

9. The system according to claim 7, wherein the terminal device unit comprises: At least one of the following: low-voltage main / sub-control equipment, high-voltage control unit, various landscape lighting execution equipment, environmental sensing equipment and supporting control system.

10. A computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the unified management and control method for heterogeneous landscape lighting devices as described in any one of claims 1-6.

Images