A multi-platform integrated lighting system and lighting control method

Abstract

This invention discloses a multi-platform integrated lighting system and lighting control method. The system includes a cloud platform, lighting terminals, an edge gateway, and a control strategy generation module with a cross-domain event-driven engine. The cloud platform integrates smart lighting, streetlights, sanitation, public toilets, advertising, and charging subsystems. This invention receives data from the smart sanitation, public toilet, and charging subsystems in real time through the cross-domain event-driven engine, dynamically generates scene lighting strategies such as energy-saving following or enhanced ventilation based on joint triggering rules, and combines differentiated billing of the billing subsystem, Pearson correlation analysis of the energy consumption analysis module, loop load offloading of the topology graph generation module, and cross-system priority linkage of the alarm overview module. This solves the problems of isolated data of multiple subsystems, fixed lighting strategies, and lack of cross-domain collaboration in the prior art, and realizes deep integration and intelligent linkage of lighting control with sanitation operations, public toilet environment, and charging load in multiple dimensions of urban operation status.

Description

Technical Field

[0001] This invention relates to the field of lighting control technology, and in particular to a multi-platform integrated lighting system and lighting control method. Background Technology

[0002] With the deepening of smart city construction, urban lighting systems have evolved from a single function of nighttime lighting to a comprehensive urban information infrastructure. Currently, some technical solutions integrate lighting control platforms with urban management functions.

[0003] In existing technologies, data from various subsystems are relatively isolated, lacking cross-domain event-driven mechanisms. For example, data on sanitation vehicle locations and work routes in the smart sanitation subsystem, ammonia concentration and pedestrian flow in the smart public toilet subsystem, and charging pile occupancy and instantaneous load in the smart charging subsystem—data that could reflect the dynamic operation of the city—are not used as decision inputs for lighting control. When sanitation vehicles enter a certain road segment for work, existing systems cannot proactively adjust the brightness of streetlights in that segment to match the work requirements based on vehicle location. When ammonia concentration in a public toilet exceeds the standard and there are pedestrians nearby, existing systems cannot use lighting changes as an effective means to guide maintenance personnel. When the load on charging piles suddenly increases, existing systems also struggle to automatically execute load unloading strategies coordinated with the lighting circuit. Furthermore, the lighting control strategies of existing systems are relatively fixed and singular, mostly based on time periods or single sensors (illuminance, human infrared) for switching or dimming, failing to dynamically link with the real-time status of multiple urban management dimensions such as sanitation, public toilets, and charging. The billing, energy consumption analysis, and alarm modules in the existing system operate independently and lack deep coupling with scene lighting policy execution records. For example, functions such as differentiated billing under different lighting policies and energy consumption correlation analysis based on multi-source data have not yet been effectively implemented.

[0004] Therefore, in response to the problems mentioned above, this invention proposes a multi-platform integrated lighting system and lighting control method. Summary of the Invention

[0005] To overcome the problem of the lack of coordination between modules and functions in the existing technology, this invention proposes a multi-platform integrated lighting system and lighting control method. The system sets up a cross-domain event-driven engine to receive real-time data from the smart sanitation, smart public toilet and smart charging subsystems, and dynamically generates scene lighting strategies based on a preset set of joint triggering rules. For example, it can jointly trigger an energy-saving following lighting scene based on the location of sanitation vehicles and the occupancy rate of charging piles, or jointly trigger an enhanced ventilation lighting scene based on the ammonia concentration in public toilets and the pedestrian presence signal of streetlights.

[0006] The technical solution of this invention is: a multi-platform integrated lighting system, comprising: The cloud platform integrates a smart lighting subsystem, a smart street light subsystem, a smart sanitation subsystem, a smart public toilet subsystem, a smart advertising subsystem, and a smart charging subsystem. Multiple lighting terminals, each lighting terminal including at least one electroluminescent light source and its driving control circuit; Multiple edge gateways, each connected to one or more lighting terminals, are used to collect the lighting terminals' operating data, energy consumption data, and topology connection data; The control policy generation module communicates and connects with the cloud platform and edge gateway. The intelligent sanitation subsystem is used to acquire real-time location data and operation route data of sanitation vehicles; the intelligent public toilet subsystem is used to acquire real-time traffic data and ammonia concentration data of public toilets; and the intelligent charging subsystem is used to acquire real-time occupancy rate data and instantaneous load data of charging piles. The control strategy generation module includes a cross-domain event-driven engine. This engine receives real-time data from the smart sanitation subsystem, the smart public toilet subsystem, and the smart charging subsystem, and dynamically generates scene lighting strategies for at least one of the lighting terminals based on a preset set of joint triggering rules. The set of joint triggering rules includes at least: The first rule is that when the intelligent sanitation subsystem instructs sanitation vehicles to enter a designated road section, and the intelligent charging subsystem instructs that the occupancy rate of charging piles in the corresponding area of ​​the road section is lower than the first threshold (15%), the "energy-saving following lighting scene" is triggered, and the luminous flux output of the lighting terminal on the designated road section is reduced from the initial value lm0 to lm1, where lm0 is generally 40%-60% of lm1.

[0007] This is because sanitation vehicles typically operate at lower speeds and are equipped with headlights. During these times, the road section is less dependent on the luminous flux output of lighting terminals than during normal periods when there are no vehicles passing by. Reducing the luminous flux to 40%-60% of the normal value can achieve energy savings of approximately 40%-50% while meeting basic road safety illumination requirements. If the reduction is less than 40%, the energy-saving effect is not significant. If the reduction is greater than 60%, it may lead to a decrease in visual recognition for pedestrians or non-motorized vehicle drivers, increasing safety hazards.

[0008] The second rule is that when the smart public toilet subsystem detects that the ammonia concentration in any public toilet exceeds the second threshold (5ppm), and the smart street light subsystem within 50 meters of the public toilet detects the presence of a pedestrian, the "enhanced ventilation and lighting scene" is triggered. This controls the lighting terminals at the entrance and surrounding areas of the public toilet to output 100% of the rated luminous flux and fluctuate the brightness at a frequency of 2Hz. The fluctuation range is ±20% of the rated luminous flux, in order to guide the attention of maintenance personnel. The scene lighting strategy is converted by the edge gateway into a PWM dimming signal (pulse width modulation signal with a frequency range of 200Hz-2000Hz) or a constant current adjustment signal for the drive control circuit of the lighting terminal, thereby realizing real-time control of the electroluminescent light source.

[0009] Preferably, the cloud platform also includes a billing subsystem, a loop control interface, a topology generation module, an energy consumption analysis module, an equipment management module, and an alarm overview module; wherein: The billing subsystem includes a dynamic billing model. This model takes the type of scene lighting strategy, execution duration, and number of lighting terminals called as input parameters and generates corresponding strategy execution bills according to preset billing standards. The electricity cost during the execution of the "energy-saving following lighting scene" is calculated at 60% of the benchmark electricity price (0.5 yuan / kWh), and the cost during the execution of the "enhanced ventilation lighting scene" is calculated at 150% of the benchmark electricity price. This additional cost is incorporated into the maintenance and management account of the smart public toilet subsystem. The loop control interface is connected to the high-voltage contactor or circuit breaker of the power distribution cabinet; when the cross-domain event-driven engine determines that the instantaneous load data from the smart charging subsystem exceeds the third threshold (80% of the rated capacity of the power distribution cabinet), it automatically generates a "load offloading lighting strategy" and disconnects the lighting loops that are pre-marked as unloadable categories through the loop control interface. The unloadable category of lighting loops is identified by the tag field in the topology connection data. The topology generation module receives the self-cascading relationship and address mapping of the connected lighting terminals reported by each edge gateway, and constructs a tree-like topology diagram of the entire lighting system using a breadth-first traversal algorithm. Each node in the topology diagram is associated with and displays the real-time input voltage (range: 198V-242V), total current (accurate to 0.1A), and power factor (accurate to 0.01) of the corresponding power distribution cabinet. Different colors are used to distinguish the classification of the lighting terminals in the smart sanitation subsystem, smart public toilet subsystem, or smart charging subsystem. The energy consumption analysis module aggregates the energy consumption data of each lighting terminal according to the time dimension, and generates at least yesterday's energy consumption bar chart (vertical axis unit: kilowatt-hour), this week's energy consumption line trend chart, and total energy consumption ring chart. The energy consumption analysis module further performs Pearson correlation analysis on the energy consumption data with the operation route data of the smart sanitation subsystem and the traffic flow data of the smart public toilet subsystem. When the absolute value of the correlation coefficient is greater than 0.7, the lighting terminal is automatically marked as a "linkage sensitive device" in the graphical interface. The device management module is used to periodically send heartbeat detection messages to the lighting terminals through the edge gateway (sending period is 5 seconds, with 3 retries after timeout), and receive response signals from the lighting terminals; the device management module counts and displays the total number of power equipment, the number of online devices, and the number of offline devices based on the heartbeat response results; when the number of offline devices accounts for more than 5% of the total, the device management module automatically generates a distribution cabinet topology integrity alarm and associates it with the topology map generation module, highlighting the offline branches in the topology map; The alarm overview module uses a sliding time window (window duration is 24 hours) to count and display the number of newly added alarms, the number of ongoing alarms, and the number of alarms that have been restored today. Each alarm entry includes at least the GIS coordinates (accuracy of 0.001 degrees) of the alarm source lighting terminal, the alarm type (including drive circuit overheating, open circuit, short circuit, and ammonia exceeding standard linkage alarm from the smart public toilet subsystem), and the handling status (unprocessed, processing, restored). Among them, the priority of the ammonia exceeding standard linkage alarm from the smart public toilet subsystem is set higher than that of the drive circuit overheating alarm (priority value: ammonia exceeding standard is level 1, overheating is level 2), and it is displayed in the graphical interface with a red flashing icon (flashing interval of 0.5 seconds).

[0010] Preferably, the cross-domain event-driven engine also includes a timing suppressor. This timing suppressor is used to automatically ignore subsequent triggers when the same set of joint triggering rules is triggered more than 3 times consecutively within a preset time window, until the time window ends. The duration of the time window is dynamically calculated based on the average driving speed of sanitation vehicles in the intelligent sanitation subsystem, specifically: Time window (unit: seconds) = (length of specified road segment, unit: meters) / (average driving speed, unit: meters / second) × 0.8; wherein, the average driving speed is between 5 km / h and 30 km / h, and when the calculated time window is less than 30 seconds, it is forcibly set to 30 seconds.

[0011] Preferably, the drive control circuit includes a rectifier and filter unit (input AC 220V±20%, output DC 310V), a power factor correction unit (corrected power factor ≥0.95), an LLC resonant converter unit (resonant frequency 80kHz-120kHz), and a PWM dimming unit based on a microcontroller (model STM32F103). The edge gateway communicates with the microcontroller to convert the scene lighting strategy into a corresponding PWM duty cycle value (0%-100%, step 1%). The microcontroller adjusts the output of the PWM dimming unit according to the duty cycle value, thereby controlling the brightness of the electroluminescent light source. At the same time, the microcontroller collects the forward voltage and current of the electroluminescent light source at a sampling rate of 10Hz. When the ratio of forward voltage to current deviates from the preset LED volt-ampere characteristic curve by more than ±10%, a drive abnormality alarm is generated and reported to the edge gateway with abnormal codes (E001: overvoltage, E002: undervoltage, E003: overcurrent, E004: short circuit).

[0012] This invention provides a lighting control method for a multi-platform integrated lighting system, comprising the following steps: S1, through the intelligent sanitation subsystem, intelligent public toilet subsystem and intelligent charging subsystem, collects and uploads in real time the location and route of sanitation vehicles (update frequency 1Hz), ammonia concentration and flow of people in public toilets (ammonia sampling cycle 5 seconds, flow of people accumulation cycle 1 minute), and charging pile load data to the cloud platform. S2, the cross-domain event-driven engine receives the above data and matches it against the set of joint triggering rules one by one; when the first rule or the second rule is matched, it proceeds to S3, otherwise it continues to listen; during the matching process, if any data source does not report new data within 3 consecutive sampling periods, it is determined that the data source is invalid and the rule is not triggered for the time being. S3, the control strategy generation module generates the corresponding scene lighting strategy according to the matched rules, and calculates the list of lighting terminals involved in the strategy and their target brightness values. The calculation adopts the lookup table method (pre-stores the GIS coordinates of each lighting terminal and the mapping table of the road segment / associated public toilet, and the mapping table is refreshed every 24 hours). S4 distributes the scene lighting policy to one or more edge gateways associated with the lighting terminal list. The distribution uses the MQTT protocol (quality of service level is at least one transmission), and the maximum number of timeout retransmissions is 3. S5, the edge gateway converts the target brightness value in the strategy into a corresponding PWM dimming signal (duty cycle resolution 0.1%) or constant current adjustment signal (current resolution 1mA), and outputs it to the drive control circuit of the lighting terminal. S6, the drive control circuit adjusts the luminous flux output of the electroluminescent light source according to the received signal, and at the same time monitors and feeds back the real-time electrical parameters (voltage, current, power, temperature) of the lighting terminal to the cloud platform at a frequency of 1Hz. S7, the cloud platform records the start time, end time (accurate to milliseconds), participating lighting terminal identifiers and energy consumption increment (cumulative energy consumption at the end time minus cumulative energy consumption at the start time) of this policy execution, for subsequent data processing and display by the billing subsystem, energy consumption analysis module and alarm overview module; all records are stored in the cloud platform time-series database and retained for 3 years.

[0013] The beneficial effects of this invention are: 1. This invention solves the technical problems of isolated data from various subsystems and inability of lighting control to be linked with multiple dimensions of urban operation status such as sanitation operations, public toilet environment and charging load in the prior art by setting up a cross-domain event-driven engine, integrating data from smart sanitation, smart public toilet and smart charging subsystems in real time and generating scene lighting strategies based on joint triggering rules. This significantly improves the intelligence level of the lighting system and the efficiency of urban management.

[0014] 2. This invention dynamically feeds back the execution records of scene lighting strategies to the billing subsystem and adopts a differentiated billing model, realizing deep coupling between lighting control strategies and cost settlement, and providing technical support for refined cost accounting and cross-departmental cost allocation for urban public facilities.

[0015] 3. This invention uses an energy consumption analysis module to perform Pearson correlation analysis on lighting energy consumption data with sanitation operation routes and public toilet traffic, and automatically marks "linkage-sensitive devices". At the same time, it uses a time-series suppressor to dynamically calculate time windows based on the speed of sanitation vehicles to avoid frequent policy triggering. This overcomes the problem that existing technologies can only perform basic energy consumption statistics and lack cross-system correlation analysis. It not only verifies the actual energy-saving effect of cross-domain linkage, but also effectively suppresses policy storms caused by data jitter, improving the stability of system operation and user experience.

[0016] 4. This invention integrates a topology graph generation module and a loop control interface. When the instantaneous load of a charging pile exceeds the threshold, it automatically disconnects the unloadable lighting circuit and highlights the offline branch in conjunction with the topology graph. At the same time, it sets the priority of the ammonia over-limit linkage alarm to be higher than that of the conventional drive alarm. This solves the problems of existing lighting systems being unable to actively coordinate with charging facilities when the power distribution load is overloaded, as well as the single alarm priority and lack of cross-subsystem linkage. It enhances the collaborative resilience of urban energy infrastructure and the rapid response capability of operation and maintenance personnel to critical events. Attached Figure Description

[0017] Figure 1 The diagram shown is a schematic representation of the overall system architecture of the present invention. Figure 2 The diagram shown illustrates the workflow of the cross-domain event-driven engine of this invention. Figure 3 The diagram shown is a schematic diagram of the lighting terminal drive control circuit of the present invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are some embodiments of the present invention, but not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] Please see Figure 1 The present invention provides an embodiment: In this embodiment, the present invention is deployed in a smart city demonstration area, which covers an area of ​​approximately 12 square kilometers and includes typical urban units such as main roads, secondary roads, back streets and alleys, public parking lots, sanitation vehicle parking lots, public restrooms and new energy charging stations.

[0020] The cloud platform is deployed in the city's data center, employing a distributed server cluster and connected to the internet via a dedicated line. Internally, the cloud platform integrates subsystems for smart lighting, smart streetlights, smart sanitation, smart public toilets, smart advertising, and smart charging. These subsystems communicate asynchronously via message queues to ensure real-time data transmission.

[0021] At the physical equipment layer, a total of 2,870 lighting terminals are deployed throughout the demonstration area. Each lighting terminal contains an electroluminescent light source (LED lamp array) and its driving control circuit. The lighting terminals are divided into 32 areas according to administrative divisions and the jurisdiction of the power distribution cabinets, with one edge gateway in each area. The edge gateway uses an industrial-grade embedded computer, possessing 4G / 5G uplink communication capabilities and RS485 / DALI downlink communication capabilities. The edge gateway connects to the lighting terminals within its jurisdiction via an RS485 bus, with each lighting terminal having a unique address on the bus. Simultaneously, the edge gateway collects parameters such as three-phase voltage, current, and power factor from the power distribution cabinets through digital input interfaces and connects to the high-voltage contactor / circuit breaker control module via an RS485 interface to achieve loop control.

[0022] The control strategy generation module is deployed within the cloud platform as a microservice. This module includes a cross-domain event-driven engine, which internally maintains a set of joint triggering rules. These rules are stored in JSON format and support dynamic loading and hot updates. The smart sanitation subsystem acquires real-time location and route data of sanitation vehicles via onboard GPS / BeiDou positioning devices, reporting data once per second with sub-meter accuracy. The smart public toilet subsystem installs an ammonia sensor and a people-counting camera in each toilet. The ammonia sensor uses an electrochemical principle, with a range of 0-20ppm, a resolution of 0.1ppm, and a sampling period of 5 seconds. The people-counting camera uses a deep learning algorithm to count the number of people entering and exiting, accumulating data over a 1-minute period. The smart charging subsystem acquires real-time occupancy data (0-100%, 0% idle, 100% occupied) and instantaneous load data (in kW, sampling period of 1 second) for each charging pile through a charging pile controller.

[0023] Please see Figure 2 The cross-domain event-driven engine continuously receives real-time data streams from the smart sanitation subsystem, smart public toilet subsystem, and smart charging subsystem, and performs time alignment and spatial correlation on the data. The engine maintains a real-time data processing pipeline, where each data point is cleaned, filtered, and formatted, and then matched against the rules in the joint triggering rule set.

[0024] Scenario 1: Energy-saving following lights for sanitation vehicles during operation: At 22:36 one day, a sanitation vehicle entered section A3 of the demonstration area. This section is approximately 800 meters long and has 46 streetlights on both sides. At this time, the smart charging subsystem reported that the occupancy rate of charging piles in the corresponding area (A3 charging station) of this section was 12%, which is lower than the first threshold of 15%. The cross-domain event-driven engine detected that both of the above conditions were met, and matched the first rule.

[0025] The engine then triggers the execution of the "Energy-Saving Follow-Up Lighting Scene". The control strategy generation module calculates the target brightness values ​​for the 46 lighting terminals on road segment A3 based on a pre-stored mapping table of lighting terminal GIS coordinates and their respective road segments: reducing the luminous flux output to 50% of the normal value. This scene lighting strategy is encapsulated in JSON format, containing a strategy ID, execution timestamp, and a list of lighting terminals (each terminal includes its address and target duty cycle value). It is then sent to the edge gateway managing road segment A3 via the MQTT protocol, with a service quality level set to at least one transmission and a maximum of three retransmissions after timeout.

[0026] After receiving the policy, the edge gateway parses the PWM duty cycle value of each lighting terminal (the normal value corresponds to a 100% duty cycle, and 50% brightness corresponds to approximately a 40% duty cycle, the specific value is determined by referring to a table based on the dimming curve of the LED beads). The edge gateway sends a dimming command to each lighting terminal via the RS485 bus. The command format includes a start code, address code, function code (dimming), high byte of duty cycle, low byte of duty cycle, and check code. After receiving the command, the microcontroller of the lighting terminal adjusts the output of the PWM dimming unit to reduce the luminous flux of the LED light source to 50% of the normal value. The dimming process uses an exponential gradient curve with a time constant τ = 2 seconds to avoid sudden brightness jumps perceived by the human eye.

[0027] Meanwhile, the cloud platform's billing subsystem records the execution of the lighting strategy for this scenario. The billing subsystem has a built-in dynamic billing model, which uses the strategy type ("Energy-Saving Follow-up Lighting Scenario"), execution duration (in this example, the sanitation vehicle took 12 minutes to pass through section A3), and the number of lighting terminals invoked (46) as input parameters. According to the preset standard, the electricity cost during the execution of this scenario is calculated at 60% of the benchmark electricity price of 0.5 yuan / kWh, i.e., 0.3 yuan / kWh. The energy consumption analysis module monitors the instantaneous power of these 46 lighting terminals in real time, calculating that the total energy consumption during the 12 minutes of executing the energy-saving scenario is 3.2 kWh. Compared to the estimated energy consumption of 5.6 kWh for normal lighting (without dimming), this represents a saving of 2.4 kWh, resulting in an energy saving rate of 42.9%.

[0028] Scenario 2: Enhanced ventilation and lighting guidance when ammonia levels in public restrooms exceed standards: At 14:24 on a certain day, the ammonia concentration in the public restroom B7 of the demonstration area was 6.2 ppm, exceeding the second threshold of 5 ppm. Simultaneously, the smart street light subsystem detected pedestrian movement within a 50-meter radius of the restroom (detected via millimeter-wave radar sensors integrated into the streetlight poles). The cross-domain event-driven engine matched the second rule.

[0029] The engine triggers the execution of the "enhanced ventilation and lighting scene." The control strategy generation module determines the lighting terminals at the entrance and surrounding areas of the public toilet, specifically including two ceiling lights above the main entrance, four floodlights on the streetlight poles on the left and right sides of the entrance, and three courtyard lights on the sidewalk in front of the toilet, totaling nine lighting terminals. The strategy requires these terminals to output 100% of their rated luminous flux and fluctuate their brightness at a frequency of 2Hz, with a fluctuation range of ±20% of the rated luminous flux. During actual operation, the microcontroller generates a rectangular wave PWM signal: during the 250ms high-level period, the output duty cycle corresponds to 120% of the rated luminous flux (achieved through short-time overdrive; the transient overcurrent capability of the LED beads allows for 120% current); during the 250ms low-level period, the output duty cycle corresponds to 80% of the rated luminous flux, with an average value of 100% of the rated luminous flux. This generates noticeable visual flicker while maintaining the average illuminance without reducing it, to draw the attention of maintenance personnel.

[0030] After the edge gateway issued the command, the nine lighting terminals simultaneously began to flash. At the same time, the cloud platform's alarm overview module generated an "Ammonia Exceedance Alarm," with the alarm source being the main light at the entrance of the public toilet, and its GIS coordinates marked. The alarm type was "Ammonia Exceedance Alarm from the Smart Public Toilet Subsystem," and the handling status was "Unprocessed." Because this alarm's priority was set higher than the drive circuit over-temperature alarm (ammonia exceeding the limit is level 1, over-temperature is level 2), it was displayed as a flashing red icon in the graphical interface (flashing interval 0.5 seconds), and the public toilet's location was highlighted on the map.

[0031] The billing subsystem also records the execution of this policy. According to the dynamic billing model, the cost during the execution of the "enhanced ventilation and lighting scenario" is calculated at 150% of the base electricity price of 0.5 yuan / kWh, which is 0.75 yuan / kWh. This scenario lasts for 8 minutes, and the total energy consumption of the 9 lighting terminals is 0.48 kWh, with a billing amount of 0.48 × 0.75 = 0.36 yuan. This additional cost is included in the maintenance management account of the smart public toilet subsystem for the accounting of public toilet operation and maintenance costs.

[0032] In this embodiment, the energy consumption analysis module reads the cumulative energy consumption value (in kilowatt-hours, with a resolution of 0.001 kilowatt-hours) from the drive control circuit of each lighting terminal every 15 minutes. After aggregating the data according to the time dimension, it generates yesterday's energy consumption, this week's energy consumption, and total energy consumption.

[0033] The energy consumption analysis module performs Pearson correlation analysis on daily energy consumption data with the operational route data of the smart sanitation subsystem (measured by sweeping mileage per road segment, in kilometers) and the pedestrian flow data of the smart public toilet subsystem (measured by daily pedestrian flow per public toilet, in person-times). The specific calculation method is as follows: For each lighting terminal, a daily energy consumption data sequence E=[e1,e2,...,e30] is continuously collected for 30 days, along with a corresponding road segment sanitation operation mileage sequence M=[m1,m2,...,m30] or a corresponding public toilet visitor flow sequence P=[p1,p2,...,p30]. The Pearson correlation coefficient r = cov(E,M) / (σ_E·σ_M) is calculated. When |r|>0.7, it is considered a strong correlation.

[0034] In actual operation data, the correlation coefficient between the lighting terminal and the sanitation operation mileage of section A3 in the demonstration area reached 0.82. The system automatically marked this lighting terminal as a "linkage-sensitive device" and labeled it with a special icon on the energy consumption analysis interface. When the user clicks on this icon, the system automatically jumps to the overlay analysis view, where maintenance personnel can intuitively see that whenever the sanitation operation mileage increases, the lighting energy consumption of this section actually decreases (because energy saving is triggered according to the lighting scene), thus verifying the actual effect of cross-domain linkage.

[0035] In this embodiment, to prevent frequent triggering of joint triggering rules within a short period of time, which could lead to drastic changes in the state of lighting terminals, the cross-domain event-driven engine incorporates a timing suppressor. This timing suppressor maintains an independent time window for each rule. Taking the first rule as an example, suppose a sanitation vehicle travels through an 800-meter section of road A3 at an average speed of 15 km / h. The timing suppressor calculates the time window as 800 / 4.17 × 0.8 ≈ 153.5 seconds. Within this 153.5-second time window, if the same joint triggering rule (i.e., the same sanitation vehicle entering the same road section and the charging pile occupancy rate is still below 15%) is triggered more than three times consecutively, the fourth and subsequent triggers will be automatically ignored until the window ends.

[0036] If the calculated time window is less than 30 seconds (for example, when sanitation vehicles travel at speeds up to 30 km / h, 800 / 8.33×0.8≈76.8 seconds, which is actually greater than 30 seconds, but for extremely short road segments, a 30-second window is forcibly used), then the 30-second window will be used. This mechanism effectively avoids repeated rule triggering due to data jitter or momentary communication anomalies.

[0037] Please see Figure 3 In this embodiment, the drive control circuit for each lighting terminal includes a rectifier and filter unit, a power factor correction unit, an LLC resonant converter unit, and a microcontroller-based PWM dimming unit. The AC 220V±20% input is rectified and filtered to approximately 310V DC. The power factor correction unit employs active PFC technology to achieve a power factor ≥0.95 after correction. The LLC resonant converter unit converts high-voltage DC to low-voltage, high-current DC, with the resonant frequency adaptively adjusted between 80kHz and 120kHz to provide a constant current source for the LED chips.

[0038] After receiving the scene lighting strategy, the microcontroller converts the target brightness value (0-100%) into the corresponding PWM duty cycle value (0%-100%, in 1% increments). The PWM dimming unit outputs a square wave signal with a frequency of 1kHz to drive the MOSFET switch, thereby adjusting the average current flowing through the LED.

[0039] The microcontroller simultaneously samples the forward voltage and current of the LED beads at a 10Hz sampling rate. Under normal operation, the volt-ampere characteristic of the LED beads approximates an exponential curve, but within the linearized drive range, the forward voltage and current have an approximately linear relationship. The microcontroller has a pre-stored standard LED volt-ampere characteristic curve table (voltage-current correspondence). When the measured voltage-current ratio deviates from the preset curve by more than ±10%, a drive abnormality is identified, generating the following abnormal codes: E001 (overvoltage, voltage exceeds rated value by 20%), E002 (undervoltage, voltage is below rated value by 30%), E003 (overcurrent, current exceeds rated value by 25%), and E004 (short circuit, voltage approaches 0 and current surges). Abnormal alarms are transmitted back to the edge gateway via the RS485 bus, and the edge gateway packages and reports them to the cloud platform.

[0040] To verify the technical effectiveness of this invention, a three-month comparative experiment was conducted in a demonstration area. The experiment was divided into a control group (using the existing EXC-ECCP platform's conventional control mode, adjusting lighting only by time period, without cross-domain linkage) and an experimental group (this invention). During the experiment, urban operation data of the demonstration area was fully recorded. The table below summarizes the comparative results of key indicators: Table 1 Comparison of key performance indicators between the experimental group and the control group.

[0041] Table 2. Actual Triggering Statistics and Benefits of Joint Triggering Rules

[0042] This example selects 10 road sections in the demonstration area to calculate the Pearson correlation coefficient between lighting energy consumption and sanitation operation mileage, as shown in the table below: Table 3. Experimental Results of Energy Consumption Correlation Analysis

[0043] The table shows that six road sections have a correlation coefficient exceeding 0.7 and were automatically marked as "linkage-sensitive equipment". Regression analysis of the data from these road sections shows that for every 1 kilometer increase in sanitation operation mileage, lighting energy consumption decreases by an average of approximately 2.3 kWh, fully demonstrating the effectiveness of energy conservation following lighting scenarios.

[0044] This example selects a road segment (800 meters long, average speed of sanitation vehicles 15 km / h) and tests the number of times the same rule is triggered during vehicle passage under both time-sequence suppressor and no time-sequence suppressor conditions. The results are shown in the table below: Table 4 Comparison Test of Timing Suppressor Effects

[0045] As can be seen from the table, the timing suppressor reduces the number of strategy executions from 9 to 3. However, the lighting terminal remains in the dimming state (50% luminous flux) after the last execution after the window period ends. Therefore, it does not affect the energy-saving effect, but greatly improves the visual experience of pedestrians.

[0046] In this embodiment, the alarm overview module uses a sliding time window (window duration of 24 hours) to statistically display the number of newly added alarms, the number of ongoing alarms, and the number of alarms restored today in real time. Each alarm entry is displayed as a card on the UI, including the GIS coordinates of the alarm source lighting terminal, the alarm type (over-temperature of the drive circuit, open circuit, short circuit, ammonia exceeding the standard linkage alarm), and the handling status (unprocessed, being processed, restored). Maintenance personnel can sort by priority, with lower priority values ​​appearing earlier.

[0047] This embodiment describes a multi-platform integrated lighting control method, specifically: S1, the intelligent sanitation subsystem uploads the location and current operation route ID of sanitation vehicles at a frequency of 1Hz via the vehicle terminal. The intelligent public toilet subsystem uploads the ammonia concentration (ppm) every 5 seconds and the cumulative value of pedestrian flow (person-times) every minute. The intelligent charging subsystem uploads the occupancy rate (0-100 integers) and instantaneous load (kW) of each charging pile every second.

[0048] S2, the cross-domain event-driven engine pulls the above data from the message queue and stores it in a memory time window (retaining data from the most recent 5 minutes). The engine defines a data dependency set for each rule. For the first rule, it depends on the location of sanitation vehicles and the occupancy rate of charging piles. The engine maintains a spatial index to quickly determine whether the vehicle coordinates fall within the polygon of a predefined road segment. If any data source does not report new data for three consecutive sampling periods (i.e., 3 seconds), the data source is considered invalid, the rule is not triggered, and a "data source disconnected" system log is generated.

[0049] When a match is found between the first or second rule, the engine records the matching time and the matching data value, and then proceeds to S3. Otherwise, the engine continues polling, with a polling period of 200 milliseconds.

[0050] S3, the control strategy generation module calls the strategy generation function based on the matched rules. The function input includes the rule type, trigger data, current time, and a pre-stored mapping table of lighting terminals (the mapping table is refreshed from the database to memory every 24 hours). An example of the mapping table structure is shown in the table below: Table 5 Scene Lighting Strategy Generation

[0051] For example, for the first rule, the strategy generator queries the 46 terminal addresses corresponding to segment A3, setting the target brightness value to 50% of the normal value (i.e., output luminous flux of 1000 lm). For the second rule, it queries the lighting terminals within a 50-meter radius of public toilet B7 (9 in this embodiment), setting the target brightness value to "fluctuation mode" (100% average luminous flux), but with additional waveform parameters: frequency 2Hz, duty cycle 50%, and rectangular waveform. After the strategy is generated, a unique strategy ID is assigned.

[0052] S4: The policy is sent to the edge gateway via the MQTT protocol, with QoS=1 during sending to ensure policy delivery. Upon receiving the policy, the edge gateway replies with an ACK. If the cloud platform does not receive the ACK within 3 seconds, it retransmits, up to 3 times. If a retransmission fails, a failure log is recorded, and an attempt is made to send the policy via a backup communication link.

[0053] S5. After receiving the policy, the edge gateway parses each entry in the lighting terminal list. For the RS485 bus, it constructs a Modbus write-hold register instruction: function code 0x06, register address is the preset dimming register (e.g., 0x1000), and data value is the duty cycle percentage (0-100). For the DALI bus, it sends the DALI command "DIRECT_ARC_POWER", with parameters 0-254 corresponding to 0-100%. The duty cycle resolution requirement is 0.1%, so the actual sent value needs to be multiplied by 2.54 and rounded down. For example, 50% brightness corresponds to a DALI value of 127. The converted instruction is sent to each lighting terminal via bus broadcast or unicast.

[0054] S6: After receiving the instruction, the microcontroller of the lighting terminal updates the duty cycle register of the PWM dimming unit. The PWM output changes the average current of the LED beads after passing through the driver circuit. At the same time, the microcontroller collects parameters such as current, power, and temperature at a frequency of 1Hz and returns them to the edge gateway via RS485 / DALI. The edge gateway packages this data, adds the edge gateway ID and timestamp, and reports it to the cloud platform in batches every 10 seconds.

[0055] After receiving the feedback data, the cloud platform writes the start and end times of this strategy execution to the time series database with millisecond precision.

[0056] Energy consumption increment calculation method: The cumulative energy consumption at the end time is subtracted from the cumulative energy consumption at the beginning time. This value can be used by the billing subsystem to calculate real-time bills, and also by the energy consumption analysis module for year-on-year analysis. All records are stored in the cloud platform time-series database and retained for 3 years to meet the city management data archiving requirements.

[0057] Furthermore, the cross-domain event-driven engine of this invention also supports deep integration with the smart advertising subsystem. During operation, the smart advertising subsystem is responsible for controlling the brightness, playback content, and runtime of advertising terminals such as LED advertising screens and light pole information screens within the demonstration area. When the smart charging subsystem reports that the instantaneous load data of charging piles in a certain area exceeds 75% of the rated capacity of the distribution cabinet but has not yet reached the third threshold of 80%, the engine triggers the "advertising load reduction lighting strategy." The control strategy generation module issues brightness limit instructions to all advertising terminals in the area through the smart advertising subsystem, reducing the maximum brightness of the advertising screen from the rated value to 60% of the rated value, while pausing high-power dynamic video advertisements and switching to static image advertisements. The electricity cost of the advertising terminal during the execution of the load reduction strategy is calculated at 80% of the benchmark electricity price, and the saved electricity cost is credited to the management account of the smart charging subsystem. If the instantaneous load of the charging pile drops back to below 60% of the rated capacity within 5 minutes, the normal brightness and playback mode of the advertising terminal are automatically restored.

[0058] Furthermore, a programmable LED stage lighting system is deployed in the civic square stage area within the demonstration zone. This system, as part of the intelligent lighting subsystem, is connected to the cloud platform. The stage lighting system includes multiple circuits for front light, top light, backlight, and color-changing lights. The cross-domain event-driven engine receives real-time instantaneous load data of charging piles reported by the intelligent charging subsystem. When the engine detects that the total load of the distribution cabinet corresponding to the stage area exceeds 85% of the cabinet's rated capacity, it triggers the "stage energy-saving lighting strategy." The control strategy generation module sends dimming commands to the stage lighting controller through the intelligent lighting subsystem, reducing the luminous flux of non-core color-changing lights and effect lights from 100% to 50% of the rated value, while simultaneously reducing the brightness of front light and top light from 100% to 70% of the rated value. All dynamic flickering and rapid color-changing effects are also paused, switching to a static monochrome gentle fixed brightness mode. During the execution of this strategy, the instantaneous power of the stage lights decreased from 45kW to approximately 28kW, a reduction of approximately 37.8%. The billing subsystem calculates electricity costs during the stage energy-saving strategy period at 80% of the benchmark electricity price using a dynamic billing model. The saved electricity costs are automatically credited to the management account of the smart charging subsystem to subsidize the operating costs of the charging piles. When the instantaneous load of the charging pile drops below 70% of the rated capacity of the distribution cabinet for three consecutive minutes, the stage lighting automatically returns to its original program operation state.

[0059] Furthermore, the millimeter-wave radar sensor integrated on each streetlight pole in this example can detect the number and direction of pedestrian movement within a 30-meter radius. The data is aggregated via an edge gateway and uploaded to the cloud platform. A cross-domain event-driven engine continuously analyzes real-time pedestrian density data for each streetlight node on each road segment. When the engine detects that the average pedestrian density on a road segment exceeds 15 people per 100 meters for 5 consecutive minutes, and the ambient light sensor for that segment shows an ambient illuminance below 15 lux (nighttime), it triggers a "pedestrian comfort lighting scene." The control strategy generation module switches the color temperature of all lighting terminals on that road segment from 4000K (cool white light) to 3000K (warm white light), simultaneously increasing the luminous flux output from 100% to 110% of the normal value, and switching the dimming curve from exponential to linear gradual change to avoid pedestrians perceiving abrupt brightness jumps. This scene aims to improve visual comfort and safety in high-traffic areas. The billing subsystem calculates electricity costs for the period of this scenario at 110% of the benchmark electricity price, with additional costs borne by the city management special account. The energy consumption analysis module records the pedestrian density and lighting energy consumption change curves before and after the scenario is triggered, which are used for subsequent lighting strategy optimization.

[0060] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments that can be applied to other fields. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A multi-platform integrated lighting system, characterized in that, include: The cloud platform integrates at least a smart lighting subsystem, a smart street light subsystem, a smart sanitation subsystem, a smart public toilet subsystem, a smart advertising subsystem, and a smart charging subsystem; Multiple lighting terminals, each lighting terminal including at least one electroluminescent light source and its driving control circuit; Multiple edge gateways, each connected to one or more lighting terminals, are used to collect the lighting terminal's operating data, energy consumption data, and topology connection data; The control policy generation module communicates and connects with the cloud platform and edge gateway. The intelligent sanitation subsystem is used to acquire real-time location data and operation route data of sanitation vehicles; the intelligent public toilet subsystem is used to acquire real-time traffic data and ammonia concentration data of public toilets; and the intelligent charging subsystem is used to acquire real-time occupancy rate data and instantaneous load data of charging piles. The control strategy generation module includes a cross-domain event-driven engine, which is used to receive real-time data from the smart sanitation subsystem, the smart public toilet subsystem and the smart charging subsystem, and dynamically generate scene lighting strategies for at least one lighting terminal based on a preset set of joint triggering rules. The scene lighting strategy is converted into a PWM dimming signal or a constant current adjustment signal for the drive control circuit of the lighting terminal through the edge gateway, so as to realize real-time control of the electroluminescent light source.

2. The multi-platform integrated lighting system according to claim 1, characterized in that, The set of joint triggering rules includes at least: The first rule is that when the intelligent sanitation subsystem instructs sanitation vehicles to enter a designated road section, and the intelligent charging subsystem instructs that the occupancy rate of charging piles in the corresponding area of ​​the road section is lower than the first threshold, the "energy-saving following lighting scene" is triggered, and the luminous flux output of the lighting terminal on the designated road section is reduced from the initial value lm0 to lm1. The second rule is that when the smart public toilet subsystem detects that the ammonia concentration in any public toilet exceeds the second threshold, and the smart street light subsystem within X meters of the public toilet detects the presence of a pedestrian, the "enhanced ventilation and lighting scene" is triggered. This controls the entrance and exit of the public toilet and the surrounding lighting terminals to output 100% of the rated luminous flux and fluctuate the brightness at a frequency of 2Hz to guide the attention of maintenance personnel.

3. The multi-platform integrated lighting system according to claim 1, characterized in that: The cloud platform also includes a billing subsystem, which contains a dynamic billing model. This dynamic billing model uses the type of scene lighting strategy, execution duration, and number of lighting terminals called as input parameters to generate corresponding strategy execution bills according to preset billing standards. Among them, the electricity cost during the execution of the "energy-saving following lighting scene" is calculated at 60% of the benchmark electricity price, while the cost during the execution of the "enhanced ventilation lighting scene" is calculated at 150% of the benchmark electricity price, and this additional cost is incorporated into the maintenance and management account of the smart public toilet subsystem. The control strategy generation module includes a loop control interface, which is connected to the high-voltage contactor or circuit breaker of the distribution cabinet. When the cross-domain event-driven engine determines that the instantaneous load data from the smart charging subsystem exceeds the third threshold, it generates a "load offloading lighting strategy" and disconnects the lighting loops that are pre-marked as unloadable categories through the loop control interface. The unloadable category of lighting loops is identified by a tag field in the topology connection data.

4. The multi-platform integrated lighting system according to claim 1, characterized in that: The cloud platform also includes a topology graph generation module. This module receives the self-cascading relationship and address mapping of the connected lighting terminals reported by each edge gateway. It constructs a tree-like topology graph of the entire lighting system using a breadth-first traversal algorithm. Each node in the topology graph is associated with and displays the real-time input voltage, total current, and power factor of the corresponding power distribution cabinet. Different colors are used to distinguish the classification of the lighting terminals in the smart sanitation subsystem, smart public toilet subsystem, or smart charging subsystem.

5. A multi-platform integrated lighting system according to claim 1, characterized in that: The cloud platform also includes an energy consumption analysis module, which aggregates the energy consumption data of each lighting terminal according to the time dimension, and generates at least yesterday's energy consumption bar chart, this week's energy consumption line trend chart, and total energy consumption ring chart. The energy consumption analysis module further performs Pearson correlation analysis on the energy consumption data, the operation route data of the smart sanitation subsystem, and the traffic flow data of the smart public toilet subsystem. When the absolute value of the correlation coefficient is greater than 0.7, the lighting terminal is automatically marked as a "linkage sensitive device" in the graphical interface.

6. The multi-platform integrated lighting system according to claim 1, characterized in that: The edge gateway is used to periodically send heartbeat detection messages to the lighting terminals and receive response signals from the lighting terminals. The cloud platform includes a device management module, which counts and displays the total number of power equipment, the number of online devices, and the number of offline devices based on the heartbeat response results. When the number of offline devices accounts for more than 5% of the total, the device management module generates a power distribution cabinet topology integrity alarm and associates it with the topology map generation module, highlighting the offline branches in the topology map.

7. A multi-platform integrated lighting system according to claim 1, characterized in that: The cloud platform also includes an alarm overview module, which uses a sliding time window to count and display the number of newly added alarms, the number of ongoing alarms, and the number of alarms that have been resolved today. Each alarm entry includes at least the GIS coordinates of the alarm source lighting terminal, the alarm type, and the handling status. Among them, the priority of the ammonia over-standard linkage alarm from the smart public toilet subsystem is set higher than the over-temperature alarm of the drive circuit, and it is displayed with a red flashing icon in the graphical interface.

8. A multi-platform integrated lighting system according to claim 1, characterized in that: The cross-domain event-driven engine also includes a timing suppressor, which is used to automatically ignore subsequent triggers when the same set of joint triggering rules is triggered more than 3 times consecutively within a preset time window, until the time window ends; the duration of the time window is dynamically calculated based on the average driving speed of sanitation vehicles in the intelligent sanitation subsystem, specifically: time window = (length of specified road segment) / (average driving speed) × 0.

8.

9. A multi-platform integrated lighting system according to claim 1, characterized in that: The drive control circuit includes a rectifier and filter unit, a power factor correction unit, an LLC resonant converter unit, and a microcontroller-based PWM dimming unit. The edge gateway communicates with the microcontroller to convert the scene lighting strategy into a corresponding PWM duty cycle value. The microcontroller adjusts the output of the PWM dimming unit according to the duty cycle value, thereby controlling the brightness of the electroluminescent light source. At the same time, the microcontroller collects the forward voltage and current of the electroluminescent light source. When the ratio of the forward voltage to the current deviates from the preset LED volt-ampere characteristic curve by more than ±10%, a drive abnormality alarm is generated and reported to the edge gateway.

10. A lighting control method for a multi-platform integrated lighting system, based on a multi-platform integrated lighting system according to any one of claims 1-9, characterized in that, Includes the following steps: S1, consisting of a smart sanitation subsystem, a smart public toilet subsystem, and a smart charging subsystem, collects and uploads data on the location and route of sanitation vehicles, ammonia concentration and traffic flow in public toilets, and charging pile load to the cloud platform in real time. S2, the cross-domain event-driven engine receives the above data and matches it against the set of joint triggering rules one by one. When the first rule or the second rule is matched, it proceeds to S3; otherwise, it continues to listen. S3, the control strategy generation module generates the corresponding scene lighting strategy according to the matched rules, and calculates the list of lighting terminals involved in the strategy and their target brightness values. S4, distribute the scene lighting policy to one or more edge gateways associated with the list of lighting terminals; S5, the edge gateway converts the target brightness value in the strategy into the corresponding PWM dimming signal or constant current adjustment signal, and outputs it to the drive control circuit of the lighting terminal. S6, the drive control circuit adjusts the luminous flux output of the electroluminescent light source according to the received signal, and at the same time monitors and feeds back the real-time electrical parameters of the lighting terminal to the cloud platform; S7, the cloud platform records the start time, end time, participating lighting terminal identifiers, and energy consumption increment of this policy execution, for subsequent data processing and display by the billing subsystem, energy consumption analysis module, and alarm overview module.

Images