Road lighting strategy customization method and system based on interface semantic self-adaption

Abstract

The application discloses a road lighting strategy customization method and system based on interface semantic self-adaption, and relates to the field of lighting strategy customization. The method comprises the following steps: sending a version query request carrying a current version number of a local lighting system to a cloud centralized knowledge base, receiving an interface semantic description returned by the cloud centralized knowledge base; calling an AI large model to perform intention recognition on a strategy application scene and an optimization target, matching corresponding interface semantic descriptions from a local cache according to a recognition result, and inputting multi-source running data into the AI large model to obtain a candidate lighting strategy; in response to a target strategy selection operation of a user, adding or switching the target strategy is completed; and monitoring actual running data of the target strategy, comparing a deviation between a predicted running index and the actual running index, and dynamically adjusting a strategy parameter. By implementing the technical scheme, the road lighting strategy can be flexibly customized, and the management efficiency of the lighting system and the energy-saving effect are improved.

Description

Technical Field

[0001] This application relates to the field of lighting strategy customization, and in particular to a method and system for customizing road lighting strategies based on interface semantic self-adaptation. Background Technology

[0002] In the fields of intelligent transportation and urban management, road lighting systems play a crucial role. Good road lighting not only improves nighttime driving safety and reduces traffic accidents, but also enhances the overall image of the city and the quality of life for residents. Furthermore, efficient lighting strategies can effectively reduce energy consumption, meeting the requirements of sustainable development and are of great significance for building green cities.

[0003] Currently, most lighting monitoring platforms in the industry have deployed strategy or plan management functions to configure and distribute street light switching times and dimming schemes. These platforms typically support users to manually formulate lighting plans through a human-machine interface, i.e., administrators set fixed switching times based on factors such as date, season, and road section, or form several lighting plans through simple conditional configurations (such as "sunset on, sunrise off", "holiday mode", etc.). However, the above-mentioned existing platforms have the following prominent problems in practical applications: (1) The acquisition and evaluation of decision factors are highly dependent on human experience and lack standardized data support. This model leads to the quality of strategy formulation varying from person to person and from time to time, making it difficult to form a replicable and quantifiable optimal solution. (2) Rigid interface adaptation and high maintenance costs for strategy expansion. When the control interface of the lighting system changes due to version upgrades, equipment replacements, or on-site customization, it is necessary to reconfigure the interface parameters or modify the platform code, resulting in high costs for strategy expansion and system maintenance. (3) The decision-making process is not transparent, and there is a risk of "AI illusion" and arbitrary decision-making. Because large models may produce illusory outputs that do not conform to physical constraints or safety specifications, direct execution poses a significant security risk.

[0004] Therefore, a road lighting strategy customization method is needed to solve the above problems. Summary of the Invention

[0005] This application provides a method and system for customizing road lighting strategies based on interface semantic self-adaptation, which can flexibly customize road lighting strategies and improve the management efficiency and energy-saving effect of lighting systems.

[0006] Firstly, this application provides a method for customizing road lighting strategies based on interface semantic self-adaptation, the method comprising: Send a version query request carrying the current version number of the local lighting system to the cloud-based centralized knowledge base, receive the interface semantic description corresponding to the current version number returned by the cloud-based centralized knowledge base and load it into the local cache. The interface semantic description includes the calling rules, parameter constraints and device influence domain of each interface of the lighting system. When a user's lighting strategy generation request is received, the lighting strategy generation request includes the strategy application scenario and optimization goal. Based on the lighting strategy generation request, the interface call rules and parameter constraints of the lighting system are obtained, and the corresponding multi-source operation data is obtained based on a preset set of decision factors according to the strategy application scenario. The AI ​​big model is invoked to identify the application scenarios and optimization goals of the strategy. Based on the identification results, the corresponding interface semantic description is matched from the local cache. The multi-source running data is then input into the AI ​​big model to obtain multiple candidate lighting strategies output by the AI ​​big model. The quantitative operation indicators and visual preview information of each candidate lighting strategy are pushed to the user terminal. In response to the user's target strategy selection operation, the strategy management interface of the lighting system is called according to the interface semantic description in the local cache. The security constraints of strategy switching are verified. After the constraints are met, the target strategy is added or switched through the strategy management interface. Monitor the actual operational data of the target strategy, compare the deviation between the predicted and actual operational indicators, and dynamically adjust the strategy parameters to form an iterative closed loop.

[0007] By adopting the above technical solution, when the lighting system interface undergoes version upgrades or changes, only the corresponding version number of the interface semantic description needs to be updated in the cloud. The edge-side proxy can automatically adapt without modifying any code or retraining and fine-tuning large models, significantly reducing system operation and maintenance costs and the difficulty of policy expansion. Before policy switching, safety constraints are verified to ensure that the operation does not cause lighting fluctuations and meets the safety requirements of industrial scenarios. After the policy goes live, actual operating data is continuously monitored and compared with predicted indicators to dynamically adjust policy parameters to form an iterative closed loop, ensuring the continuity of energy-saving effects and the stability of lighting quality.

[0008] In some embodiments, obtaining the corresponding multi-source operational data based on a preset set of decision factors according to the strategy application scenario includes: The application scenario of the strategy is analyzed. If the application scenario of the strategy does not specify a specific area or road segment, the scope of application selection option is pushed to the user terminal so that the user can specify the scope of application of the strategy. Metadata of each area or road segment within the scope of the policy is retrieved from the local private data storage unit. The metadata includes the number of light poles, equipment online rate, road grade, and historical operation data. The system retrieves the planned light-on / off times from the local cache, calls the weather data interface to obtain real-time weather data for each area, and retrieves pedestrian / vehicle traffic data for each area at the hourly granularity from the local private data storage unit to construct a dataset that includes multiple decision factors such as planned light-on / off times, illuminance, weather, and pedestrian / vehicle traffic. The various decision factors are quantified and assigned values, and weighted scores are calculated according to preset weight coefficients. The weighted scores are then added to the multi-source running data, and the sum of the weight coefficients is one.

[0009] By adopting the above technical solution, the application scenario of the strategy is analyzed, and the user is proactively pushed with the option to select the scope of application when no specific area or road segment is specified, and the user is guided to specify it. This avoids the failure of strategy generation or the default global strategy not meeting expectations due to the user's omission of scope settings. After the scope is confirmed, the metadata of each area / road segment within the scope is automatically retrieved, realizing the fully automatic aggregation of multi-source heterogeneous data. Users do not need to manually query and enter various data, which significantly reduces the complexity of operation and time cost, while improving the data integrity and accuracy of strategy generation.

[0010] In some embodiments, the step of matching the corresponding interface semantic description from the local cache based on the recognition result, and inputting the multi-source runtime data into the AI ​​big model to obtain multiple candidate lighting strategies output by the AI ​​big model specifically includes: The weighted scoring results from the multi-source operational data are combined with the strategy application scenario and optimization objective to generate strategy prompts. The prompts are then input into the AI ​​big model to obtain candidate lighting strategies, which include dimming ratio parameters for each time period. The preset dimming ratio lower limit parameter is obtained from the interface semantic description in the local cache. For each dimming ratio parameter in each time period of each candidate lighting strategy, the dimming ratio lower limit parameter is compared with the dimming ratio lower limit parameter to generate a corrected candidate lighting strategy. The rated luminous flux of the lighting system and the road surface reflectance are obtained based on the interface semantic description in the local cache. Combined with the weather visibility coefficient in the multi-source operation data, the predicted road surface illuminance of each modified candidate lighting strategy at different time periods is calculated. Based on the energy consumption data of the currently effective strategy, the expected energy saving rate of each modified candidate lighting strategy is calculated. The compliance illuminance threshold is obtained based on the interface semantic description in the local cache. The compliance of the predicted road surface illuminance of each corrected candidate lighting strategy is determined based on the compliance illuminance threshold. The compliance status of each strategy in each time period is marked. The corrected dimming ratio parameter, predicted road surface illuminance, expected energy saving rate and compliance status are correlated and used as the output data source of the quantitative operation index.

[0011] By employing the above technical solution, the semantic understanding and policy generation capabilities of the large model are deeply integrated with the hardware constraints of the lighting system itself. This ensures that the final generated candidate policies possess both the flexibility to adapt to different scenarios and strict compliance with equipment physical limitations and industry standards. This avoids the problem of purely large model-generated solutions outputting unexecutable policies due to a lack of understanding of underlying hardware constraints. The abstract policy solutions generated by the large model are transformed into quantifiable illuminance values, comparable energy-saving rates, and traceable compliance status, among other multi-dimensional indicators. This allows users to intuitively understand the differences and advantages / disadvantages between different policies, providing a sufficient basis for subsequent policy selection.

[0012] In some embodiments, the step of calling the policy management interface of the lighting system according to the interface semantic description in the local cache, verifying the security constraints of policy switching, and completing the addition or switching of the target policy through the policy management interface after the constraints are met, specifically includes: Retrieve the currently active system-planned light-on / off times from the local cache and determine if the current system time falls within the light-on period; If the current system time is during the lighting period, the automatic strategy switching will be refused, and a manual operation prompt and risk warning information will be pushed to the user terminal. If the current system time is during the non-lighting period, a secondary confirmation request will be sent to the user terminal. The secondary confirmation request includes the expected energy saving rate of the target strategy and a switching risk warning. After receiving a positive response from the user, the instruction set of the target policy is preloaded according to the interface semantic description in the local cache, and the device connectivity of the policy management interface is verified. If the verification passes, a switching instruction is issued; if the verification fails or no device confirmation is received within a timeout, the policy is automatically rolled back to the original policy and the reason for the failure is recorded. After a successful policy switch, an operation audit log is generated. The audit log includes the operation subject identifier, operation type, operation content description, operation timestamp, and associated policy version number. The audit log is then stored in the local audit database.

[0013] The above technical solution employs a two-phase commit mechanism during the switching process. First, the target policy instruction set is pre-loaded based on the interface semantic description, and device connectivity is verified. Only after successful verification is the switching instruction issued. If verification fails or no device confirmation is received within a timeout period, the system automatically rolls back to the original policy and records the reason for failure. This prevents inconsistencies in system status or incomplete policy execution due to factors such as device offlineness or network anomalies during policy switching. It ensures that every policy change is traceable to the specific operating entity, operation time, and changed content, providing a complete and tamper-proof audit evidence chain for subsequent security compliance checks and fault diagnosis, meeting the stringent requirements of traceable and auditable operation and maintenance in industrial lighting scenarios.

[0014] In some embodiments, after obtaining the corresponding multi-source operational data based on a preset set of decision factors according to the strategy application scenario, the method further includes weather difference verification and control mode generation, specifically including: Call the weather data interface to obtain the future time period weather data of each region within the scope of the strategy. The weather data includes weather type, visibility coefficient and precipitation probability. Traverse each region and calculate the weather difference value between any two regions. If the weather difference value between any two regions exceeds the preset threshold, push the weather difference prompt and strategy splitting suggestion to the user terminal. Based on the weather data of each region, candidate control modes corresponding to each region are generated. The control modes include a first mode and a second mode. The first mode is a light control-assisted mode that triggers the switching on and off of lights by illuminance within the light control buffer window, based on the system's planned switching on and off time. The second mode is a dual-effect mode that forces the lights to turn on within the system's planned switching on and off time range and triggers the switching on and off of lights by illuminance outside the planned time range. The interface semantic description in the local cache is read to obtain the deployment status of the illuminance collector. If the deployment status indicates that the illuminance collector has been deployed, the edge-side intelligent execution agent will use the first mode or the second mode as the control mode of the candidate strategy, and set the light-on trigger threshold and the light-off trigger threshold according to the illuminance threshold parameters stored in the interface semantic description. If the deployment status indicates that no illuminance collector has been deployed, the light control buffer window of the first mode is extended from the first duration to the second duration, and the second mode is switched to a time control mode that relies entirely on the system's scheduled light switching time to execute the light switching.

[0015] By adopting the above technical solution and combining it with two candidate control modes generated for each region, a refined strategy coverage of different microclimate areas within the scope is achieved. This avoids the dual dilemma of "excessive lighting and energy waste in sunny areas, and insufficient illumination affecting safety in rainy and snowy areas" caused by the uniform strategy used in traditional solutions. By reading the interface semantic description in the local cache to obtain the deployment status of the illuminance collector, automatic perception of local hardware configuration is achieved instead of relying on manual configuration. This allows the same strategy customization method to adaptively adapt to lighting systems with different hardware configurations, eliminating the need to develop different versions of control logic for different hardware configurations, and significantly improving the versatility and deployment flexibility of the solution.

[0016] In some embodiments, after receiving the interface semantic description corresponding to the current version number returned by the cloud-based centralized knowledge base and loading it into the local cache, the method further includes incremental knowledge updates, specifically including: Upon receiving an update notification pushed by the cloud-based centralized knowledge base, an incremental update query request is sent to the cloud-based centralized knowledge base. The incremental update query request carries the version identifier of the current interface semantic description in the local cache. The system receives an incremental difference data packet returned by the cloud-based centralized knowledge base. The incremental difference data packet is generated by the cloud-based centralized knowledge base after comparing the version identifier with the latest version stored in the cloud. The incremental difference data packet contains a semantic description of the change interface of the latest version relative to the version identifier. The semantic description of the change interface is accompanied by a change type tag. The change type tag is used to indicate adding an interface, modifying an interface, or deleting an interface. If the change type label is "Add Interface" or "Modify Interface", the corresponding change interface semantic description will be added to or replaced in the local cache for the corresponding version number of the interface semantic description set. If the change type label is "Delete Interface", the corresponding interface in the local cache will be marked as obsolete and removed from the interface semantic description set. After completing the incremental merging, the version identifier of the locally cached interface semantic description is updated to the version identifier of the latest version. When a user's lighting policy generation request is received subsequently, the interface matching and invocation are automatically performed based on the updated interface semantic description.

[0017] By adopting the above technical solution, when only a few interfaces in the cloud knowledge base change, the edge agent only needs to receive the data packets of the changed parts instead of re-downloading the complete set of interface semantic descriptions. This significantly saves network transmission bandwidth and shortens synchronization time, demonstrating outstanding engineering practical value, especially in edge deployment scenarios with limited network conditions. The explicit deletion handling logic effectively avoids policy execution failures caused by the edge side incorrectly calling invalid interfaces due to retaining deleted interface definitions, ensuring the consistency of the knowledge base update process and the accuracy of subsequent policy calls.

[0018] In some embodiments, after the target policy is added or switched through the policy management interface after the constraints are met, the method further includes policy effect verification and intelligent rollback, specifically including: After the target strategy is switched and takes effect, a preset effect verification period is started. During the effect verification period, actual operation data during the operation of the target strategy is collected at a first acquisition frequency higher than the conventional monitoring frequency. The actual operation data includes real-time energy consumption data of each loop and real-time illuminance data of each illuminance sensor location. The actual operating data collected during the effect verification period is compared with the predicted operating indicators on a time-by-time basis. The actual energy consumption deviation rate and actual illuminance deviation value for each time period are calculated. If the actual illuminance deviation value is negative and lower than the compliance illuminance threshold, the deviation type is marked as a safety risk deviation. If the actual energy consumption deviation rate is positive and the actual illuminance deviation value does not exceed the compliance illuminance threshold, the deviation type is marked as an abnormal energy consumption deviation. If the deviation type is a security risk deviation, an automatic rollback is triggered, a security alarm and an automatic rollback notification are pushed to the user terminal, and the policy management interface of the lighting system is called to switch back to the original policy according to the interface semantic description in the local cache. If the deviation type is an energy consumption abnormal deviation and the deviation rate exceeds the preset energy consumption rollback threshold, an energy consumption abnormality prompt and rollback suggestion are pushed to the user terminal, and the rollback is executed in response to the user's confirmation operation. If no rollback is triggered within the effect verification period, the edge-side intelligent execution agent will associate the actual running data within the effect verification period with the corresponding predicted running indicators and the actual adopted strategy parameters and store them in the local audit database as historical reference data. If a rollback is triggered, the rollback event and the reason for the rollback will be recorded in the audit log, and the reactivation of the target strategy will be suspended until a manual confirmation instruction from the user is received.

[0019] By adopting the above technical solution, the system can automatically identify whether the policy problem is due to "substandard lighting quality" or "lower-than-expected energy-saving effect," providing an accurate basis for subsequent targeted handling measures and avoiding the problems of unaddressed safety hazards or misjudged policy failures caused by general judgments. Differentiated rollback strategies are executed based on the type of deviation, avoiding frequent automatic rollbacks due to non-critical issues that would hinder effective policy verification. Furthermore, after a rollback is triggered, the policy is temporarily suspended until manual confirmation by the user, preventing problematic policies from being repeatedly activated without addressing the root cause.

[0020] In a second aspect, embodiments of this application provide a computer system including a memory, a processor, and a computer program stored in the memory; the processor executes the computer program to implement the steps of the method described in any possible implementation of the first aspect.

[0021] Thirdly, embodiments of this application provide a computer-readable storage medium having a computer program / instructions stored thereon, which, when executed by a processor, implement the steps of the method described in any possible implementation of the first aspect.

[0022] Fourthly, embodiments of this application provide a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps of the method described in any possible implementation of the first aspect.

[0023] It is understood that the computer system provided in the second aspect, the storage medium provided in the third aspect, and the computer program product provided in the fourth aspect are all used to execute the method provided in this application. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here.

[0024] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages: 1. When the lighting system control interface undergoes a version upgrade or interface change, it is only necessary to update the corresponding version number of the interface semantic description in the cloud knowledge base. The edge agent can then accurately pull the new interface definition through the version number and automatically adapt. The AI ​​large model does not need to memorize or pre-train any interface format. It completes the interface call entirely based on the dynamically loaded interface semantic description, which fundamentally eliminates the maintenance cost of readjusting the model or modifying the prompt words when the interface changes, and realizes zero-code expansion of strategy capabilities. 2. By calling the AI ​​big model to identify the application scenarios and optimization goals of the strategy, and matching the corresponding interface semantic descriptions from the local cache based on the identification results, a precise mapping from user natural language requests to specific system interfaces is achieved; after inputting multi-source operating data into the big model, a variety of candidate lighting strategies are obtained, and the quantitative operating indicators and visual preview information of each candidate strategy are pushed to the user terminal for the user to choose from, which improves the user's trust and acceptance of AI-generated strategies and effectively solves the problem of implementation resistance caused by the inexplicability of decision-making in industrial scenarios; 3. Before switching strategies, the strategy management interface is called according to the interface semantic description, and safety constraints are verified to ensure that the switching operation is executed within the allowed time window, avoiding automatic switching during lighting periods that could cause light cluster flickering or sudden changes in illuminance. After the strategy goes live, actual operating data is continuously monitored, and the deviation between predicted and actual operating indicators is compared. Strategy parameters are dynamically adjusted to form an iterative closed loop, enabling the strategy to be continuously optimized based on real operating results rather than being fixed after a one-time generation. Before strategy execution, safety constraints ensure the operational reliability of the industrial site, and after execution, closed-loop iteration ensures the continuity of energy-saving effects and the long-term stability of lighting quality. Attached Figure Description

[0025] Figure 1 This is a flowchart illustrating the road lighting strategy customization method based on interface semantic self-adaptation in the embodiments of this application; Figure 2 This is a schematic diagram of the cloud-edge collaborative architecture in the embodiments of this application; Figure 3 This is a schematic diagram of the multi-strategy simulation optimization process in the embodiments of this application; Figure 4 This is a schematic diagram of the closed-loop iterative optimization process in the embodiments of this application; Figure 5 This is a schematic diagram of an exemplary hardware structure of a computer system in an embodiment of this application. Detailed Implementation

[0026] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to any or all possible combinations including one or more of the listed items.

[0027] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0028] The following is combined with Figure 1 The method of the embodiments of this application will be described below.

[0029] Please see Figure 1 This is a flowchart illustrating the road lighting strategy customization method based on interface semantic self-adaptation in this application embodiment. The method is applied to an edge-side intelligent execution agent, such as... Figure 1 As shown, the method includes the following steps: S101. Send a version query request carrying the current version number of the local lighting system to the cloud-based centralized knowledge base, receive the interface semantic description corresponding to the current version number returned by the cloud-based centralized knowledge base and load it into the local cache. The interface semantic description includes the calling rules, parameter constraints and device influence domain of each interface of the lighting system. S102. When a user's lighting strategy generation request is received, the lighting strategy generation request includes the strategy application scenario and optimization goal. Based on the lighting strategy generation request, the interface call rules and parameter constraints of the lighting system are obtained, and the corresponding multi-source operation data is obtained based on a preset set of decision factors according to the strategy application scenario. S103. Call the AI ​​big model to perform intent recognition on the application scenario and optimization target of the strategy, match the corresponding interface semantic description from the local cache according to the recognition result, and input the multi-source running data into the AI ​​big model to obtain multiple candidate lighting strategies output by the AI ​​big model. S104. Push the quantitative operation indicators and visual preview information of each candidate lighting strategy to the user terminal. In response to the user's target strategy selection operation, call the strategy management interface of the lighting system according to the interface semantic description in the local cache, verify the security constraints of strategy switching, and complete the addition or switching of the target strategy through the strategy management interface after the constraints are met. S105. Monitor the actual operating data of the target strategy, compare the deviation between the predicted operating indicators and the actual operating indicators, and dynamically adjust the strategy parameters to form an iterative closed loop.

[0030] After the edge-side intelligent execution agent starts, it automatically sends a version query request to the cloud-based centralized knowledge base. This request carries the current version number and product code of the local lighting system. The cloud-based centralized knowledge base is deployed on a public or private cloud server and stores only general, de-identified rule-based data. The knowledge base includes an interface semantic description sub-base, which stores compiled interface semantic descriptions according to the lighting system version number (e.g., V2.0, V2.1), defining the calling rules, parameter constraints, and device influence domains for each version control interface. The interface semantic description sub-base is indexed by product code + version number, with each version number corresponding to an independent set of interface semantic descriptions, ensuring strict consistency between interface rules and the local lighting system version. The cloud-based centralized knowledge base queries the interface semantic description sub-base for an interface semantic description that precisely matches the version number. If a match is found, the cloud returns it to the edge-side intelligent execution agent; if no match is found, the cloud returns a version incompatibility warning and pushes the latest compatible version number corresponding to the product code for the edge-side intelligent execution agent to choose from. After receiving the returned interface semantic description, the edge-side intelligent execution proxy loads it into the local cache. If another version of the interface semantic description already exists in the local cache, the newly loaded interface semantic description replaces the old version, completing the hot update of the local cache. The interface semantic description is generated by converting the interface documentation of the lighting system according to preset compilation rules. Specifically, after receiving the Swagger JSON uploaded by the lighting system, the cloud-based centralized knowledge base converts it into a structured interface semantic description according to preset compilation rules. The conversion rules include: extracting the interface path from the Swagger's paths field, extracting the HTTP method from the method field, extracting the query parameters and types from the parameters field, and extracting the request body parameters and structure from the requestBody field. At the same time, custom extended fields are used to annotate interface side effects (e.g., write for write operation), device impact domains (e.g., lamp_group for lamp group level), and interface-specific constraints (e.g., "prohibited during light-on periods"). The interface semantic description contains the calling rules, parameter constraints, and device impact domains of each interface of the lighting system. The calling rules define the endpoint path, request method, required parameters, and optional parameters of the interface; parameter constraints define the type, value range, and format requirements of each parameter; and the device influence domain defines the range of devices affected by the interface call (e.g., single lamp level, lamp group level, or area level). Through a version number-driven dynamic loading mechanism for interface semantic descriptions, the AI ​​large model does not need to memorize or pre-train any interface format; it completes interface calls entirely based on dynamically loaded interface semantic descriptions. When the control interface of the lighting system changes due to version upgrades or on-site customization, only the corresponding version number of the interface semantic description needs to be updated in the cloud knowledge base. The edge proxy can then accurately pull the new interface definition based on the version number and automatically adapt, without modifying any code or retraining or fine-tuning the large model.

[0031] Users initiate policy generation requests via the "AI Assistant" button on the front-end interface. The system server pushes the current system context information, including the system center latitude and longitude, the planned on / off times for the day, and the currently effective policy ID, to the edge-side intelligent execution agent via a message queue. The edge-side intelligent execution agent listens to the message queue and updates the context information to its local cache. When a user initiates a policy generation request, the request includes the policy application scenario and optimization goals. Based on the interface semantic descriptions already loaded into the local cache, the edge-side intelligent execution agent extracts the interface call rules and parameter constraints of the lighting system. These rules and constraints include: endpoint paths, request methods, parameter structures, side effect labels, device impact domains, and interface-specific constraints for each interface. The edge-side intelligent execution agent first parses the policy application scenario to determine the policy's scope. If the policy application scenario does not specify a specific area or road segment, it pushes a scope selection option to the user's terminal, allowing the user to specify all global areas or a specific area / road segment. If the user selects a specific area / road segment, the agent automatically checks the online rate of devices within that area: if the online rate is below 95%, it marks the policy as risky and prompts the user that "some devices in this area are offline, and the policy may not be fully effective." If the user selects a global policy, the agent proceeds to the next stage. The edge-side intelligent execution agent, based on the determined policy scope, retrieves metadata for each area / segment within that scope from its local private data storage unit. This metadata includes the number of light poles, device online rate, road classification, and historical operational data. Subsequently, the agent retrieves the system's planned light-on / off times from its local cache, calls the weather data interface to obtain real-time weather data for each area, and retrieves pedestrian / vehicle traffic data for each area from its local private data storage unit at an hourly granularity. The edge-side intelligent execution agent quantifies and assigns values ​​to the various decision factors obtained, and calculates a weighted score according to preset weight coefficients. The decision factors include four categories: system planned light-on / off times, illuminance, weather, and pedestrian / vehicle traffic. The weight coefficients are set based on lighting industry standards: system planned light-on / off times have a weight coefficient of 0.4, illuminance has a weight coefficient of 0.3, weather has a weight coefficient of 0.2, and pedestrian / vehicle traffic has a weight coefficient of 0.1, with the sum of all factor weights being 1. The specific quantitative rules are as follows: the system's planned light-on / off time is used as the baseline time axis, and the time offset of all strategies must not exceed ±60 minutes; the illuminance is based on the light-on threshold of 30 lux and the light-off threshold of 50 lux, and if there is no illuminance collector, it will automatically switch to weather compensation mode; the weather type is mapped to the compensation coefficient (sunny=1.0, cloudy=1.1, light rain=1.2, heavy rain / haze=1.3, the higher the coefficient, the earlier the lights are turned on and the later they are turned off); the pedestrian / vehicle traffic is divided into three levels according to the hourly traffic: peak (≥800 vehicles / hour), off-peak (300-800 vehicles / hour), and low-peak (<300 vehicles / hour), corresponding to different dimming ratio ranges.The edge-side intelligent execution agent quantifies and assigns values ​​to the four types of decision factors, calculates a weighted score according to preset weight coefficients, and adds the weighted score results to the multi-source running data.

[0032] The edge-side intelligent execution agent invokes the AI ​​big model to identify the application scenarios and optimization goals of the strategy. In this application, the AI ​​big model plays the role of intent understanding and tool call orchestration. The AI ​​big model understands the user's input natural language requests such as "Help me generate an energy-saving strategy," maps them into a structured strategy generation task, and completes data acquisition and strategy generation according to a preset tool call plan. The edge-side intelligent execution agent invokes the AI ​​big model to identify the application scenarios and optimization goals of the strategy. Based on the application scenarios and optimization goals, the AI ​​big model identifies the strategy type and constraints corresponding to the user's intent. According to the identification results, the edge-side intelligent execution agent matches the corresponding interface semantic description from the locally cached interface semantic description. The edge-side intelligent execution agent combines the weighted scoring results from multi-source runtime data with the strategy application scenarios and optimization goals to form strategy generation prompts. These prompts include: the scope of the strategy, the weighted scoring results of four types of decision factors, the optimization goal, and the interface call rules and parameter constraints extracted from the interface semantic description. The edge-side intelligent execution agent inputs the constructed strategy generation prompts into the AI ​​big model, and the AI ​​big model outputs multiple candidate lighting strategies based on the prompts. Candidate lighting strategies include at least three types: balanced strategy, conservative strategy, and energy-saving strategy. Each candidate strategy contains dimming ratio parameters for each time period. The edge-side intelligent execution agent performs simulation calculations for each candidate lighting strategy. The simulation calculations obtain the rated luminous flux of the lighting system's luminaires and the road surface reflectance coefficient based on the interface semantic description in the local cache, and combine this with the weather visibility coefficient from multi-source operational data to calculate the predicted road surface illuminance for each candidate strategy at different time periods; and calculate the expected energy saving rate for each candidate strategy based on the energy consumption data of the currently effective strategy. The edge-side intelligent execution agent performs compliance verification on the dimming ratio of each candidate lighting strategy according to the parameter constraints in the interface semantic description in the local cache. The verification rules include: if the calculated dimming ratio value for a certain time period is lower than the preset dimming lower limit, it is automatically adjusted to the dimming lower limit; if it is higher than 100%, it is limited to 100%. The edge-side intelligent execution agent obtains the compliance illuminance threshold based on the interface semantic description in the local cache, and judges the compliance of the predicted road surface illuminance of each corrected candidate lighting strategy according to the compliance illuminance threshold, marking the compliance status of each strategy in each time period. Finally, the corrected dimming ratio parameters, predicted road surface illuminance, expected energy saving rate, and compliance status are correlated and used as the output data source for quantitative operation indicators.

[0033] The edge-side intelligent execution agent pushes a simulated streetlight map to the front end via the WebSocket protocol. This simulated streetlight map overlays the GIS coordinates of the light poles, dimming status, weather icons, and traffic heatmaps. The pushed data is in JSON structured format. Quantitative operational indicators include: predicted road illuminance after dimming, energy saving rate compared to the current operating strategy, power saving rate compared to rated energy consumption, and compliance status. Users can view the simulated streetlight map and quantitative indicator comparison table for each candidate strategy through the front-end interface and select a target strategy based on the visual information. The user's selection is transmitted to the edge-side intelligent execution agent through the front-end interface. Responding to the user's target strategy selection, the edge-side intelligent execution agent first verifies the security constraints for strategy switching. Security constraint verification includes: calling the currently effective system plan for switching on and off lights in the local cache to determine if the current system time is within the lighting period. If the current system time is within the lighting period, automatic strategy switching is rejected, and a manual operation prompt and risk warning are pushed to the user terminal. If the current system time is outside the lighting period, a secondary confirmation request is sent to the user terminal, including the expected energy saving rate of the target strategy and a switching risk warning. After receiving a positive response from the user, the edge-side intelligent execution agent invokes the lighting system's policy management interface based on the interface semantic description stored in the local cache. Policy switching employs a two-phase commit mechanism: In the first phase, the target policy's instruction set is preloaded based on the interface semantic description in the local cache, and the device connectivity of the policy management interface is verified. If the verification passes, the second phase begins, issuing the switching command. If the first phase verification fails or the second phase times out without device confirmation, the policy is automatically rolled back to the original policy, and the reason for failure is recorded. Upon successful policy switching, the edge-side intelligent execution agent automatically generates an operation audit log. The audit log includes the operation subject identifier, operation type, operation content description, operation timestamp, and associated policy version number. The audit log is stored in a local audit database.

[0034] The edge-side intelligent execution agent accesses the local lighting system's data storage unit via a dedicated AI-powered user interface, collecting operational data from the past 24 hours at preset intervals. The collected data includes: meter readings for each circuit during strategy operation, real-time road surface brightness data collected by illuminance sensors deployed along the road, lamppost online rates, and fault alarm records. The edge-side intelligent execution agent compares the collected actual operational data with the predicted operational indicators from the strategy simulation phase: calculating the deviation rate between actual and predicted values ​​for each time period, and checking whether the actual illuminance for each time period meets the minimum limits specified in the CJJ 45-2015 standard. If the actual illuminance is significantly higher than the standard requirements, the agent generates energy-saving optimization suggestions, prompting a reduction in the dimming ratio to a lower level and estimating additional energy savings. If the actual illuminance is lower than the standard limit, the agent generates safety alarm suggestions, prompting a reduction in the dimming ratio to a level that ensures driving safety. The edge-side intelligent execution agent pushes the deviation analysis results and optimization suggestions to the user terminal. In response to the user's confirmation of the optimization suggestion, the agent invokes the lighting system's policy management interface based on the interface semantic description in the local cache to incrementally adjust the dimming ratio parameters or time period division parameters of the currently effective policy. If the user adopts the optimization suggestion and verifies its effectiveness, the agent reports the verified optimization rule to the error correction and optimization sub-repository of the centralized knowledge base in the cloud. Subsequently, when other edge-side intelligent execution agents at other customer sites pull knowledge base updates, they will automatically inherit the optimization rule, achieving zero-code reuse of cross-domain knowledge.

[0035] Figure 2 This is a schematic diagram of the cloud-edge collaborative architecture in an embodiment of this application, such as... Figure 2As shown, the overall deployment logic is as follows: A centralized knowledge base server is deployed in the cloud, storing only general, de-identified rule-based data, including an interface semantic description sub-library, a runtime constraint rule sub-library, and an error correction and optimization sub-library. The interface semantic description sub-library is indexed according to the system version number (e.g., V2.0, V2.1, V3.0), with each version corresponding to an independent set of interface semantic descriptions, defining the calling rules, parameter constraints, and device impact domains for each version's control interfaces. The runtime constraint rule sub-library stores cross-scenario general security rules, and the error correction and optimization sub-library stores general optimization rules verified by multiple customer sites. Local servers are deployed at the customer site as the runtime carrier for the edge-side intelligent execution agent. The local server includes a RAG retrieval tool, a tool orchestration and scheduling engine, a message push module, a local context cache unit (storing center latitude and longitude, planned light switching times, currently effective policy IDs, etc.), and a local data storage unit (storing user-private data such as energy consumption, pedestrian flow, illuminance, and device status). The edge-side intelligent execution agent allows AI-dedicated users (with only read-only permissions) to directly query the local database, achieving a 3-5 times efficiency improvement compared to calling REST interfaces. Data synchronization between the cloud and local servers is achieved via HTTPS, transmitting only incremental or full interface semantic descriptions and rules downstream, with no user-private data being uploaded. A context synchronization channel is established between the local server and the front-end interface via a message queue (such as RabbitMQ / Kafka). When a front-end user clicks the "AI Assistant" button, the lighting system service pushes context information (center latitude and longitude, planned light on / off times, currently effective policy ID, etc.) to the message queue, and the edge-side intelligent execution agent listens and updates its local cache. After the policy is generated, the agent completes the target policy operation through the lighting system service's policy management interface (providing add, switch, and query functions).

[0036] Figure 3 This is a schematic diagram of the multi-strategy simulation optimization process in the embodiments of this application, such as... Figure 3As shown, the overall process is as follows: The user initiates a policy request through the front-end interface. After receiving the request, the edge-side intelligent execution agent first parses the policy application scenario. If the user does not specify a specific area or road segment, the agent pushes an option to select the scope of application, asking whether to select all areas globally or a specific area / road segment. After the user confirms, the scope of application of the policy is determined. The edge-side intelligent execution agent calls the weather API to obtain future weather data for each area within the scope of application and iterates through each area to calculate the weather difference between each pair of areas. If the weather differences between areas are significant, the agent pushes a prompt to the user, suggesting that a separate policy be customized for rainy areas; if the weather differences are within a reasonable range, the agent directly enters the control mode selection. After entering the control mode selection, the edge-side intelligent execution agent determines whether to use the first mode (primary time control and secondary light control) or the second mode (dual time control and light control) based on the deployed illuminance collectors. Based on the pedestrian / vehicle traffic data retrieved from the local private data storage unit, the dimming time period is divided into hourly granularities (peak hours, off-peak hours, and low-peak hours), and the dimming ratio compliance is verified in conjunction with the dimming ratio lower limit parameter obtained from the interface semantic description. After completing the above data preparation, the edge-side intelligent execution agent calls the AI ​​large model to generate multiple candidate strategies (balanced, conservative, and energy-saving). For each candidate strategy, simulation calculations and risk verification are performed to calculate predicted road surface illuminance, expected energy-saving rate, and compliance status. Subsequently, the simulated lighting map, predicted illuminance, energy-saving rate, and compliance status, among other quantitative operational indicators, are sent to the front-end user terminal via a push preview interface for user viewing and selection. After the user selects a target strategy, the edge-side intelligent execution agent calls the lighting system's strategy management interface to add the strategy, but by default, activation and switching are not performed; the strategy is in an inactive state. The user is prompted to manually activate the strategy or asked whether to switch strategies, and relevant operation audit logs are recorded. After the user confirms the switch during non-lighting hours, the strategy switch is executed through a two-phase commit mechanism.

[0037] Figure 4 This is a schematic diagram of the closed-loop iterative optimization process in an embodiment of this application, such as... Figure 4As shown, the overall process is as follows: After the edge-side intelligent execution agent starts the daily monitoring task, it first logs into the local lighting system through the AI-dedicated operation user, directly accesses the local data storage unit, and collects the actual operating data during the target strategy's operation during the previous day's lighting period. This includes actual energy consumption data for each circuit, actual illuminance data for each illuminance sensor location, and equipment status data such as the online rate of light poles and fault alarm records. After collection, the agent compares the actual operating data with the predicted operating indicators calculated by simulation for each time period, calculates the energy consumption deviation rate and illuminance deviation value for each time period, and simultaneously verifies the compliance of the actual illuminance based on the compliance illuminance threshold stored in the interface semantic description. If all deviations are within the preset threshold range, a strategy operation summary is pushed to the user terminal, informing the user that the current strategy is operating normally and no adjustment is needed. If there are significant deviations, the agent generates branches for differentiated optimization suggestions based on the specific type of deviation. Scenario A is an excessive dimming scenario, where the actual illuminance exceeds the compliant illuminance threshold and is outside the reasonable range. The agent generates energy-saving optimization suggestions, prompting an appropriate reduction in the dimming ratio and estimating additional energy-saving gains. Scenario B is an insufficient dimming scenario, where the actual illuminance is below the compliant illuminance threshold. The agent generates a safety alarm suggestion, prompting an increase in the dimming ratio to ensure driving safety. Scenario C is a frequent switching point scenario, where the strategy frequently switches dimming states between adjacent time periods. The agent generates stability optimization suggestions, prompting adjustments to the switching point threshold or extending the buffer window to avoid light flicker. Each scenario corresponds to a different optimization direction, and the agent pushes differentiated optimization suggestions to the user terminal for user confirmation. After the user confirms and adopts the optimization suggestions, the agent calls the lighting system's strategy management interface based on the interface semantic description in the local cache, incrementally adjusting the dimming ratio parameters or time period division parameters of the currently effective strategy, and storing the adjustment records in the local audit database. Verified effective optimization rules can be reported to the error correction and optimization sub-library of the cloud-centralized knowledge base, achieving zero-code reuse of cross-domain knowledge.

[0038] In some embodiments, obtaining the corresponding multi-source operational data based on a preset set of decision factors according to the strategy application scenario includes: The application scenario of the strategy is analyzed. If the application scenario of the strategy does not specify a specific area or road segment, the scope of application selection option is pushed to the user terminal so that the user can specify the scope of application of the strategy. Metadata of each area or road segment within the scope of the policy is retrieved from the local private data storage unit. The metadata includes the number of light poles, equipment online rate, road grade, and historical operation data. The system retrieves the planned light-on / off times from the local cache, calls the weather data interface to obtain real-time weather data for each area, and retrieves pedestrian / vehicle traffic data for each area at the hourly granularity from the local private data storage unit to construct a dataset that includes multiple decision factors such as planned light-on / off times, illuminance, weather, and pedestrian / vehicle traffic. The various decision factors are quantified and assigned values, and weighted scores are calculated according to preset weight coefficients. The weighted scores are then added to the multi-source running data, and the sum of the weight coefficients is one.

[0039] The edge-side intelligent execution agent first parses the policy application scenario input by the user. The policy application scenario is a component of the policy generation request initiated by the user through the front-end interface, such as "XX main road," "XX industrial park," or "citywide." If the policy application scenario explicitly specifies a specific area or road segment, the agent directly uses that specified area as the policy's scope. If the policy application scenario does not specify a specific area or road segment, the agent pushes a scope selection option to the user's terminal, allowing the user to specify "all areas globally" or "specific area / road segment." This interactive design aims to avoid policy generation failure due to the user omitting the scope setting, or the default use of a global policy that cannot meet the differentiated needs of local areas. After the user completes the selection, the agent determines the policy's scope based on the user-specified range.

[0040] Once the policy's scope is determined, the edge-side intelligent execution agent retrieves metadata for each area or road segment within that scope from the local private data storage unit. This local private data storage unit is deployed on the customer's local server, storing user-owned private data and not uploading it to the cloud. The metadata includes the following: number of light poles (the total number of lighting devices in the area / segment, used to confirm policy coverage and assess the scale of dimming commands); device online rate (the ratio of online light poles to the total number of light poles; if the online rate is below a preset threshold, the policy is flagged as risk and the user is alerted to avoid the policy not fully taking effect due to some devices being offline); road classification (expressway, arterial road, secondary arterial road, or local road; different road classifications correspond to different illuminance compliance standards); and historical operational data (energy consumption data and device operation status records for the area / segment over past periods, used as a benchmark for subsequent energy-saving rate calculations and policy effect comparisons).

[0041] The edge-side intelligent execution agent acquires four types of decision factor data from three data sources to construct a structured decision factor dataset. The first type of decision factor is the system's planned light-on / off time. The agent directly retrieves the currently effective system-planned light-on and light-off times from its local cache. This data originates from the system's pre-configured time control plan, serving as the basic time benchmark for the daily operation of the lighting system and determining the reference origin for the strategy's light-on / off time offset. The second type of decision factor is illuminance. After calling the weather data interface to obtain real-time weather data for each region, the agent extracts illuminance information. If the system has deployed illuminance collectors, it acquires the collectors' real-time readings; otherwise, it estimates illuminance based on weather type using a weather compensation model. The third type of decision factor is weather. The agent calls the weather data interface to obtain real-time weather data for each region, including weather type (sunny, cloudy, light rain, heavy rain, haze, etc.), visibility coefficient, and precipitation probability. Different weather types directly affect the road surface illumination requirements and the timing of switching lights on and off. Rain, snow, fog, and haze reduce visibility, requiring higher illumination levels and earlier light-on times to ensure driving safety. The fourth decision factor is pedestrian / vehicle traffic. The agent retrieves pedestrian / vehicle traffic data for each area from its local private data storage unit at an hourly granular level. This data is derived from historical statistics (such as the average traffic flow for the same period over the past 30 days), and the hourly granular division facilitates precise planning of dimming transition points in subsequent strategies. Based on traffic volume, time periods can be divided into peak periods (≥800 vehicles / hour), off-peak periods (300-800 vehicles / hour), and low-peak periods (<300 vehicles / hour). Different traffic levels correspond to different dimming ratio ranges. Peak periods require 100% illumination to maintain traffic safety, while low-peak periods allow for deep energy conservation.

[0042] The heterogeneity of multi-source data means it cannot be directly input into a large AI model for unified processing. The system's planned light-on / off time is a point in time, weather is a textual description, and traffic flow is a numerical value; their dimensions and semantics are different. Therefore, the agent needs to quantify and assign values ​​to these four decision factors separately, converting them into a unified numerical scoring result. The system's planned light-on / off time serves as the baseline timeline, and its quantified value reflects the positional relationship of the current time relative to the planned light-on / off time. The offset of the light-on / off time for all strategies must not exceed ±60 minutes (except in extreme weather). Illuminance is quantified based on a light-on threshold of 30 lx (the lower limit for compliance on secondary roads) and a light-off threshold of 50 lx (to avoid accidental switching). The lower the actual illuminance is compared to the light-on threshold, the higher the light-on demand score. Weather type is mapped to a compensation coefficient: sunny = 1.0, cloudy = 1.1, light rain = 1.2, heavy rain / haze = 1.3. Higher coefficients indicate more severe weather and higher lighting demand. Pedestrian / vehicle traffic flow is mapped to different scoring intervals according to the aforementioned three levels; higher traffic flow results in a higher lighting demand score. After quantification and assignment, the agent calculates a weighted score according to preset weighting coefficients. These weighting coefficients are set based on lighting industry standards: the system's planned on / off time, as the fundamental constraint for lighting control, has the highest weight at 0.4; illuminance directly determines whether lights need to be turned on and the dimming level, with the next highest weight at 0.3; weather indirectly affects lighting demand by influencing visibility and road surface reflection conditions, with a weight of 0.2; pedestrian / vehicle traffic significantly affects lighting demand only during certain times and on certain road sections, with a weight of 0.1. The sum of the four weighting coefficients is 1, ensuring that the weighted score results are normalized to a unified dimension.

[0043] In some embodiments, the step of matching the corresponding interface semantic description from the local cache based on the recognition result, and inputting the multi-source runtime data into the AI ​​big model to obtain multiple candidate lighting strategies output by the AI ​​big model specifically includes: The weighted scoring results from the multi-source operational data are combined with the strategy application scenario and optimization objective to generate strategy prompts. The prompts are then input into the AI ​​big model to obtain candidate lighting strategies, which include dimming ratio parameters for each time period. The preset dimming ratio lower limit parameter is obtained from the interface semantic description in the local cache. For each dimming ratio parameter in each time period of each candidate lighting strategy, the dimming ratio lower limit parameter is compared with the dimming ratio lower limit parameter to generate a corrected candidate lighting strategy. The rated luminous flux of the lighting system and the road surface reflectance are obtained based on the interface semantic description in the local cache. Combined with the weather visibility coefficient in the multi-source operation data, the predicted road surface illuminance of each modified candidate lighting strategy at different time periods is calculated. Based on the energy consumption data of the currently effective strategy, the expected energy saving rate of each modified candidate lighting strategy is calculated. The compliance illuminance threshold is obtained based on the interface semantic description in the local cache. The compliance of the predicted road surface illuminance of each corrected candidate lighting strategy is determined based on the compliance illuminance threshold. The compliance status of each strategy in each time period is marked. The corrected dimming ratio parameter, predicted road surface illuminance, expected energy saving rate and compliance status are correlated and used as the output data source of the quantitative operation index.

[0044] The edge-side intelligent execution agent combines the weighted scoring results from multi-source operational data with the strategy application scenario and optimization objective to generate strategy prompts. The structured construction logic of these prompts is as follows: the strategy application scenario defines the scope of the strategy, such as "XX main road" or "citywide"; the optimization objective clarifies the optimization direction of the strategy, such as "energy saving priority," "illuminance priority," or "balanced consideration"; and the weighted scoring results provide numerical constraints on four decision factors (system planned light switching time, illuminance, weather, and pedestrian / vehicle traffic). After combining these three parts into a complete strategy prompt, the edge-side intelligent execution agent inputs it into the AI ​​big model. The AI ​​big model generates candidate lighting strategies based on these prompts. Candidate lighting strategies include at least three types: balanced strategies (balancing energy saving and compliance, suitable for most scenarios), conservative strategies (higher illuminance redundancy, suitable for rainy, snowy, foggy, and hazy weather), and energy-saving strategies (highest energy saving rate, suitable for the late night when traffic is extremely low). Each candidate strategy includes dimming ratio parameters for different time periods, such as 100% during peak hours, 55%-65% during off-peak hours, and 40%-55% during low-peak hours. Dimming ratio parameters directly generated by the AI ​​model may fall below the physically executable lower limit due to a lack of understanding of underlying hardware constraints, causing some lights to fail to execute dimming commands as expected after the strategy is issued. To address this, the edge-side intelligent execution agent retrieves a preset lower limit parameter for the dimming ratio from the interface semantic description cached locally. This lower limit parameter is an inherent constraint of the lighting system interface, defined in the parameter constraint field of the interface semantic description. For each candidate lighting strategy, the dimming ratio parameters for each time period are compared item by item with the lower limit parameter. If the calculated dimming ratio for a certain time period is lower than this lower limit, it is automatically adjusted upwards to the lower limit; if it is higher than 100%, it is limited to 100%. For example, if the dimming lower limit is defined as 10% in the interface semantic description, but the AI ​​large model generates a dimming ratio of 8% for off-peak periods, the agent will automatically correct it to 10% to ensure that the dimming ratio parameter in the corrected candidate lighting strategy strictly meets the hardware executable range of the lighting system interface.

[0045] The revised candidate lighting strategies meet hardware constraints in terms of dimming ratio parameters, but users still need to understand the actual lighting effects and energy-saving benefits of each strategy before selecting one. Therefore, the edge-side intelligent execution agent performs simulation calculations for each revised candidate lighting strategy. The predicted road illuminance is calculated based on the following parameters: the rated luminous flux of the lighting system's luminaires (unit: lumens, reflecting the light output capability of the luminaires at rated power) and the road surface reflectance coefficient (reflecting the light reflection characteristics of the road surface material; different materials have different reflectance coefficients, directly affecting the effective illuminance reaching the road surface) are obtained from the interface semantic description in the local cache; combined with the weather visibility coefficient from multi-source operational data (different weather types correspond to different visibility coefficients, for example, 1.0 for sunny days and 0.7 for hazy days; this coefficient reflects the attenuation effect of weather on light propagation). Based on the above parameters, combined with the dimming ratio parameters and pole spacing for each time period, the predicted road illuminance for each revised candidate lighting strategy at different time periods is calculated. The expected energy saving rate is calculated based on the energy consumption data of the currently effective strategy. Historical energy consumption data of the currently effective strategy during the same period are read from the local private data storage unit. The predicted energy consumption of the candidate strategy (estimated based on the ratio of dimming ratio to rated power) is compared with the actual energy consumption of the current strategy, and the expected energy saving rate of each corrected candidate lighting strategy compared with the current operating strategy is calculated.

[0046] Whether the predicted road surface illuminance calculated by simulation meets industry standards is a key decision-making basis for users' strategy selection. The edge-side intelligent execution agent obtains the compliance illuminance threshold based on the interface semantic description in the local cache. This threshold comes from the operational constraint rules in the lighting system interface semantic description, and its value is based on the minimum illuminance requirements for expressways, main roads, secondary roads, and branch roads at different times as specified in the lighting industry standards. The agent performs time-by-time compliance judgment on the predicted road surface illuminance of each corrected candidate lighting strategy based on the compliance illuminance threshold: if the predicted road surface illuminance of a certain time period is higher than or equal to the compliance illuminance threshold, the time period is marked as "compliant"; if it is lower than the compliance illuminance threshold, it is marked as "non-compliant" and the deviation range is indicated. Finally, the corrected dimming ratio parameters, predicted road surface illuminance, expected energy saving rate, and compliance status are associated and stored as the output data source of quantitative operation indicators. This data source will be pushed to the user terminal's visualization interface via the WebSocket protocol in subsequent steps, allowing users to intuitively compare and select strategies in the simulated lighting map and quantitative indicator comparison table.

[0047] In some embodiments, the step of calling the policy management interface of the lighting system according to the interface semantic description in the local cache, verifying the security constraints of policy switching, and completing the addition or switching of the target policy through the policy management interface after the constraints are met, specifically includes: Retrieve the currently active system-planned light-on / off times from the local cache and determine if the current system time falls within the light-on period; If the current system time is during the lighting period, the automatic strategy switching will be refused, and a manual operation prompt and risk warning information will be pushed to the user terminal. If the current system time is during the non-lighting period, a secondary confirmation request will be sent to the user terminal. The secondary confirmation request includes the expected energy saving rate of the target strategy and a switching risk warning. After receiving a positive response from the user, the instruction set of the target policy is preloaded according to the interface semantic description in the local cache, and the device connectivity of the policy management interface is verified. If the verification passes, a switching instruction is issued; if the verification fails or no device confirmation is received within a timeout, the policy is automatically rolled back to the original policy and the reason for the failure is recorded. After a successful policy switch, an operation audit log is generated. The audit log includes the operation subject identifier, operation type, operation content description, operation timestamp, and associated policy version number. The audit log is then stored in the local audit database.

[0048] After responding to the user's target policy selection, the edge-side intelligent execution agent first performs security constraint checks before policy switching, rather than directly calling the policy management interface to execute the switch. The agent retrieves the currently effective system's planned on / off times from the local cache, determining if the current system time falls within the on-time period (i.e., the time between the planned on-time and planned off-time). If the current system time falls within the on-time period, the agent refuses to automatically execute the policy switch and pushes a manual operation prompt and risk warning to the user terminal. The technical consideration behind this design is that during the on-time period, the lighting system is providing traffic lighting services to the road. If AI automatically triggers electronic dimming or switching, it may cause lighting fluctuations such as flashing lights and sudden changes in illuminance, directly affecting road safety. Restricting policy switching to non-on-time periods (such as daytime standby mode) fundamentally avoids the timing conflict between AI automatic operation and normal lighting services. If the current system time falls outside the on-time period, the agent initiates a secondary confirmation request to the user terminal, including the expected energy saving rate of the target policy and a switching risk warning. The purpose of the secondary confirmation mechanism is to address the time gap between policy selection and policy switching, even though users have already selected a target policy during the policy preview phase. Users may make an initial selection based on visual information during the preview phase but may not yet fully understand the specific impact of that selection during the actual switch. By carrying the expected energy saving rate and switching risk warnings in the secondary confirmation request, users are ensured to have a final opportunity to review their decision before the switch is executed.

[0049] After receiving a positive response from the user, the edge-side intelligent execution agent invokes the lighting system's policy management interface to execute the policy switch based on the interface semantic description stored in the local cache. To avoid inconsistencies in system state due to factors such as device offline or network anomalies during the switch, a two-phase commit mechanism is adopted. The first phase is the preloading and verification phase. The agent preloads the instruction set of the target policy (i.e., the complete parameter structure required by the policy management interface, including dimming ratio parameters for each time period, scope identifier, effective time configuration, etc.) based on the interface semantic description stored in the local cache, and verifies the device connectivity of the policy management interface, i.e., confirming that the lighting system's policy management interface is currently responsive and that devices within the policy's scope are online. If the verification passes, the process proceeds to the second phase. The second phase is the execution phase. The agent issues the switch command through the policy management interface. If the first phase verification fails or the second phase times out without receiving device confirmation, the agent automatically triggers a rollback to the original policy and records the reason for the failure. The technical advantage of the two-phase commit mechanism is that it avoids system state inconsistency when half of the devices have received the new policy and half of the devices are still executing the original policy, thus ensuring the atomicity of the policy switching operation. Either all devices successfully switch to the new policy, or all devices retain the original policy.

[0050] After a successful policy switch, the edge-side intelligent execution agent automatically generates an operation audit log. The audit log includes the following fields: operation subject identifier (administrator account ID or AI identifier performing the operation), operation type (policy addition / policy switch / parameter modification), operation description (e.g., "Switch the policy from conservative to energy-saving"), operation timestamp (accurate to milliseconds), and associated policy version number. The audit log is stored in a local audit database. The data structure design of this audit log ensures that every policy change can be traced back to the specific operation subject, operation time, and changed content, providing a complete audit evidence chain for subsequent security compliance checks and troubleshooting.

[0051] In some embodiments, after obtaining the corresponding multi-source operational data based on a preset set of decision factors according to the strategy application scenario, the method further includes weather difference verification and control mode generation, specifically including: Call the weather data interface to obtain the future time period weather data of each region within the scope of the strategy. The weather data includes weather type, visibility coefficient and precipitation probability. Traverse each region and calculate the weather difference value between any two regions. If the weather difference value between any two regions exceeds the preset threshold, push the weather difference prompt and strategy splitting suggestion to the user terminal. Based on the weather data of each region, candidate control modes corresponding to each region are generated. The control modes include a first mode and a second mode. The first mode is a light control-assisted mode that triggers the switching on and off of lights by illuminance within the light control buffer window, based on the system's planned switching on and off time. The second mode is a dual-effect mode that forces the lights to turn on within the system's planned switching on and off time range and triggers the switching on and off of lights by illuminance outside the planned time range. The interface semantic description in the local cache is read to obtain the deployment status of the illuminance collector. If the deployment status indicates that the illuminance collector has been deployed, the edge-side intelligent execution agent will use the first mode or the second mode as the control mode of the candidate strategy, and set the light-on trigger threshold and the light-off trigger threshold according to the illuminance threshold parameters stored in the interface semantic description. If the deployment status indicates that no illuminance collector has been deployed, the light control buffer window of the first mode is extended from the first duration to the second duration, and the second mode is switched to a time control mode that relies entirely on the system's scheduled light switching time to execute the light switching.

[0052] After acquiring multi-source operational data, the edge-side intelligent execution agent does not directly enter the strategy generation process of the AI ​​large model. Instead, it first verifies the differences in weather data for each region within the policy's scope. It calls the weather data interface to obtain future time-period weather data for each region within the policy's scope, including weather type (sunny, cloudy, light rain, heavy rain, haze, etc.), visibility coefficient, and precipitation probability. It then iterates through each region, calculating the weather difference between each pair of regions. The calculation of the weather difference value is based on a comprehensive quantification of the differences in the severity of weather types, the deviation in visibility coefficients, and the difference in precipitation probability between regions. If the weather difference value between any two regions exceeds a preset threshold (e.g., region A is sunny, region B is experiencing heavy rain, and the difference in precipitation probability exceeds 60%), a weather difference alert and strategy splitting suggestion are pushed to the user terminal. This alerts the administrator that the current weather conditions vary significantly across regions, suggesting that separate strategies be customized for regions with severe weather conditions, rather than applying a uniform control strategy to the entire city.

[0053] Based on weather data for each region, candidate control modes are generated for each region. The control modes include a first mode and a second mode, each with different on / off trigger logic to adapt to different hardware configurations and application scenarios. The first mode is a primary time-controlled and secondary light-controlled mode. This mode uses the system's planned on / off time as a baseline, setting a light control buffer window (default first duration 30 minutes) before the planned on time. The on time = planned on time - buffer window duration. Within this buffer window, the lights are only triggered when the illuminance drops to the on-time trigger threshold (e.g., 30 lux); otherwise, they are forced to turn on at the end of the window. The off time = planned off time + buffer window duration. Within this buffer window, the lights are only triggered when the illuminance rises to the off-time trigger threshold (e.g., 50 lux); otherwise, they are forced to turn off at the end of the window. In scenarios with illuminance collectors, this mode can achieve on-demand lighting using light control while ensuring that on / off switching is not extremely delayed or premature through time control boundaries. The second mode is a dual-effect time-controlled and light-controlled mode. This mode forces the lights to remain on within the planned on / off time frame, independent of illuminance trigger conditions. Outside the planned time frame, it relies entirely on illuminance sensor readings to determine whether to turn the lights on or off, supporting multiple on / off switching within a day. This mode is suitable for scenarios with high requirements for lighting continuity, ensuring that the lighting is not accidentally turned off by light control during the planned time period.

[0054] The agent reads the interface semantic description from the local cache to obtain the deployment status of the illuminance collector. The interface semantic description pre-stores the hardware configuration information of the lighting system, including whether illuminance collectors are deployed, their deployment location, and quantity. If the deployment status indicates that illuminance collectors are deployed, the agent selects either the first or second mode as the control mode for the candidate strategy and sets the light-on and light-off trigger thresholds according to the illuminance threshold parameters stored in the interface semantic description. Specifically, the light-on trigger threshold is set to 30 lux (the lower limit for compliance on secondary roads), and the light-off trigger threshold is set to 50 lux (to avoid frequent switching of lights due to illuminance fluctuations). By dynamically reading the threshold parameters from the interface semantic description instead of hard-coding them, the threshold configuration can be uniformly managed through a cloud knowledge base and adjusted without modifying the agent code.

[0055] If the deployment status indicates that no illuminance collector has been deployed, the agent automatically activates weather compensation mode. Specifically, the light control buffer window of the first mode is extended from the first duration (default 30 minutes) to the second duration (e.g., 60 minutes), meaning lights are turned on 60 minutes earlier and turned off 60 minutes later. This compensates for the lack of information when there is no real-time illuminance feedback, ensuring timely lighting services under any weather conditions through a longer buffer window. Simultaneously, the second mode is switched to a pure time-controlled mode that relies entirely on the system's scheduled light-on / off times, disabling illuminance triggering logic. The buffer window extension factor in weather compensation mode is related to the weather type in the weather data; the extension factor for rain, snow, fog, and haze is greater than that for sunny days.

[0056] In some embodiments, after receiving the interface semantic description corresponding to the current version number returned by the cloud-based centralized knowledge base and loading it into the local cache, the method further includes incremental knowledge updates, specifically including: Upon receiving an update notification pushed by the cloud-based centralized knowledge base, an incremental update query request is sent to the cloud-based centralized knowledge base. The incremental update query request carries the version identifier of the current interface semantic description in the local cache. The system receives an incremental difference data packet returned by the cloud-based centralized knowledge base. The incremental difference data packet is generated by the cloud-based centralized knowledge base after comparing the version identifier with the latest version stored in the cloud. The incremental difference data packet contains a semantic description of the change interface of the latest version relative to the version identifier. The semantic description of the change interface is accompanied by a change type tag. The change type tag is used to indicate adding an interface, modifying an interface, or deleting an interface. If the change type label is "Add Interface" or "Modify Interface", the corresponding change interface semantic description will be added to or replaced in the local cache for the corresponding version number of the interface semantic description set. If the change type label is "Delete Interface", the corresponding interface in the local cache will be marked as obsolete and removed from the interface semantic description set. After completing the incremental merging, the version identifier of the locally cached interface semantic description is updated to the version identifier of the latest version. When a user's lighting policy generation request is received subsequently, the interface matching and invocation are automatically performed based on the updated interface semantic description.

[0057] When changes occur in the interface semantic descriptions in the centralized knowledge base in the cloud, such as additions, modifications, or deletions, the cloud pushes an update notification to the edge-side intelligent execution agent via a WebHook mechanism. Upon receiving this notification, the edge-side intelligent execution agent does not blindly re-download the full set of interface semantic descriptions from the cloud. Instead, it sends an incremental update query request to the centralized knowledge base in the cloud, carrying the version identifier of the current interface semantic description in its local cache. Upon receiving the incremental update query request, the centralized knowledge base in the cloud compares the version identifier provided by the agent with the latest version stored in the cloud, identifying the interface semantic description entries that differ between the two versions. The cloud only packages the changed parts into an incremental difference data package and returns it to the agent, rather than returning the complete set of interface semantic descriptions. This incremental difference data package contains the changed interface semantic descriptions corresponding to the latest version relative to the agent's current version, and each changed interface semantic description is accompanied by a change type tag to indicate the specific type of change—adding an interface, modifying an interface, or deleting an interface. After receiving the incremental difference data package returned by the cloud, the edge-side intelligent execution agent performs a differentiated local merging operation based on the change type tag. When the change type label indicates a new interface, the agent directly adds the corresponding interface semantic description to the local cache's set of interface semantic descriptions for the corresponding version number. When the change type label indicates a modified interface, the agent replaces the old version's interface semantic description in the local cache with the modified one. When the change type label indicates a deleted interface, the agent marks the corresponding interface in the local cache as obsolete and removes it from the set of interface semantic descriptions. Through this differentiated merging logic, the set of interface semantic descriptions in the local cache remains precisely consistent with the latest version in the cloud. It should be noted that the special handling logic for deletion operations has important technical considerations. If the semantic description of the deleted interface is simply removed from the set without marking it, the AI ​​model will fail to generate a policy if it matches the deleted interface during subsequent policy generation because it cannot find the corresponding interface semantic description. By marking the interface as obsolete, the agent can identify and exclude obsolete interfaces in advance during the interface matching stage, avoiding processing anomalies caused by invalid matches.

[0058] After incremental merging is complete, the edge-side intelligent execution agent updates the version identifier of the locally cached interface semantic description to the latest version identifier in the cloud. Subsequently, when the agent receives another user's lighting policy generation request, it will automatically perform interface matching and invocation based on the updated interface semantic description, without user intervention or agent restart. This incremental knowledge update mechanism significantly reduces network transmission overhead and synchronization time by transmitting only the differing data instead of the full data when changes occur in the cloud knowledge base, making it particularly valuable for engineering applications in edge deployments with limited network conditions.

[0059] In some embodiments, after the target policy is added or switched through the policy management interface after the constraints are met, the method further includes policy effect verification and intelligent rollback, specifically including: After the target strategy is switched and takes effect, a preset effect verification period is started. During the effect verification period, actual operation data during the operation of the target strategy is collected at a first acquisition frequency higher than the conventional monitoring frequency. The actual operation data includes real-time energy consumption data of each loop and real-time illuminance data of each illuminance sensor location. The actual operating data collected during the effect verification period is compared with the predicted operating indicators on a time-by-time basis. The actual energy consumption deviation rate and actual illuminance deviation value for each time period are calculated. If the actual illuminance deviation value is negative and lower than the compliance illuminance threshold, the deviation type is marked as a safety risk deviation. If the actual energy consumption deviation rate is positive and the actual illuminance deviation value does not exceed the compliance illuminance threshold, the deviation type is marked as an abnormal energy consumption deviation. If the deviation type is a security risk deviation, an automatic rollback is triggered, a security alarm and an automatic rollback notification are pushed to the user terminal, and the policy management interface of the lighting system is called to switch back to the original policy according to the interface semantic description in the local cache. If the deviation type is an energy consumption abnormal deviation and the deviation rate exceeds the preset energy consumption rollback threshold, an energy consumption abnormality prompt and rollback suggestion are pushed to the user terminal, and the rollback is executed in response to the user's confirmation operation. If no rollback is triggered within the effect verification period, the edge-side intelligent execution agent will associate the actual running data within the effect verification period with the corresponding predicted running indicators and the actual adopted strategy parameters and store them in the local audit database as historical reference data. If a rollback is triggered, the rollback event and the reason for the rollback will be recorded in the audit log, and the reactivation of the target strategy will be suspended until a manual confirmation instruction from the user is received.

[0060] Once the target strategy switch is complete and takes effect, the edge-side intelligent execution agent immediately initiates a pre-set effect verification period. This effect verification period runs only for a short period after the strategy switch (e.g., 2 or 4 hours after the switch), with the core purpose of rapidly verifying and evaluating the new strategy. This time window is designed based on the following considerations: the initial operational phase immediately after the new strategy switch is the stage where various deviations are first exposed, and it is also a window period before the execution status of the original strategy is fully covered. Quickly identifying and rolling back serious deviations during this phase can minimize the negative impact of the strategy switch on lighting services. During the effect verification period, the edge-side intelligent execution agent collects actual operational data during the target strategy's operation at a higher first-order sampling frequency than the regular monitoring frequency. The regular monitoring frequency is typically once a day, while the first-order sampling frequency can be set to the minute level (e.g., once every 5 minutes) to ensure that a sufficient density of data samples is obtained within the limited verification period for deviation assessment. The actual operational data includes real-time energy consumption data for each loop and real-time illuminance data for each illuminance sensor location. Loop-level energy consumption data acquisition can accurately locate loops with abnormal energy consumption, rather than just obtaining the overall average energy consumption of the strategy; illuminance sensor-level illuminance data acquisition can reflect the spatial distribution of road illuminance, avoiding the influence of measurement deviations at individual locations on the overall judgment.

[0061] The edge-side intelligent execution agent compares the actual operating data collected during the effect verification period with the predicted operating indicators calculated by simulation on a time-by-time basis. The meaning of time-by-time comparison is that the strategy has different dimming ratios in different time periods (peak, off-peak, and low-peak periods), and the actual illuminance and actual energy consumption may differ significantly in different time periods. Therefore, it is necessary to perform one-to-one deviation calculations for each time period. Based on the time-by-time comparison results, the actual energy consumption deviation rate and actual illuminance deviation value for each time period are calculated. The actual illuminance deviation value reflects the difference between the actual illuminance and the predicted illuminance; a positive value indicates that the actual illuminance is higher than the predicted value, and a negative value indicates that the actual illuminance is lower than the predicted value. The agent classifies the deviation type into two categories based on the nature of the deviation. The first category is safety risk deviation: when the actual illuminance deviation value is negative (i.e., the actual illuminance is lower than the predicted value) and lower than the compliance illuminance threshold, it is marked as a safety risk deviation. The compliance illuminance threshold is derived from the lighting industry standards stored in the interface semantic description. When the actual illuminance is lower than this threshold, it means that the road illuminance no longer meets the minimum requirements for driving safety, constituting a safety risk. The second category is abnormal energy consumption deviation: When the actual energy consumption deviation rate is positive (i.e., the actual energy consumption is higher than the predicted value) and the actual illuminance deviation value does not exceed the compliant illuminance threshold, it is marked as abnormal energy consumption deviation. The core characteristic of this type of deviation is that the illuminance is within the compliant range and does not pose a safety threat, but the energy consumption is significantly higher than expected, indicating that the energy-saving effect of the strategy has not achieved the expected goal.

[0062] Depending on the type of deviation, the edge-side intelligent execution agent implements differentiated rollback strategies, reflecting the core principle of prioritizing safety over energy conservation. If the deviation is a safety risk deviation, the agent triggers automatic rollback, pushes a safety alarm and automatic rollback notification to the user terminal, and calls the lighting system's policy management interface to switch back to the original policy based on the interface semantic description in the local cache. Safety risk deviations involve road illuminance not meeting compliance requirements, directly affecting driving safety. Once confirmed, regardless of the deviation magnitude, rollback measures should be taken immediately to eliminate safety hazards. Automatic rollback does not require user confirmation, ensuring safety risks are addressed as quickly as possible. If the deviation is an energy consumption anomaly deviation and the deviation rate exceeds the preset energy consumption rollback threshold, the agent pushes an energy consumption anomaly prompt and rollback suggestion to the user terminal, and executes the rollback after user confirmation. Energy consumption anomalies do not involve safety issues, giving users ample decision-making time to decide whether to rollback based on actual operating conditions, avoiding frequent automatic rollbacks due to poor energy-saving effects that could hinder policy verification. If no rollback is triggered during the effectiveness verification period, it indicates that the target strategy has neither generated security risks nor shown significant energy consumption anomalies in actual operation. The agent will associate the actual operating data during the effectiveness verification period with the corresponding predicted operating indicators and the actual strategy parameters used, and store them in the local audit database as historical reference data for subsequent iterative optimization. If a rollback is triggered, the agent will record the rollback event and the reason for the rollback in the audit log, and temporarily suspend the reactivation of the target strategy until it receives a manual confirmation instruction from the user.

[0063] The road lighting strategy customization method based on interface semantic self-adaptation in the embodiments of this application has been described above. The computer system in the embodiments of this application will be described in detail below in conjunction with the above-described road lighting strategy customization method based on interface semantic self-adaptation.

[0064] Please see Figure 5 This is a schematic diagram of an exemplary hardware structure of a computer system in an embodiment of this application.

[0065] In some embodiments, the computer system 500 includes a computer device, which may be a terminal device. The computer device includes a processor 501, a memory 502, a sensor module 503, a communication module 504, an input device 505, and an output device 506 connected via a system bus. The processor 501 of the computer device provides computing and control capabilities. The memory 502 of the computer device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database is used to store data.

[0066] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0067] In some embodiments of this application, a computer-readable storage medium is provided, including instructions that, when executed on the computer system 500, cause the computer system 500 to execute the road lighting strategy customization method based on interface semantic self-adaptation as described in the embodiments of this application.

[0068] In some embodiments of this application, a computer program product is also provided, which, when run on a computer system 500, causes the computer system 500 to execute the road lighting strategy customization method based on interface semantic self-adaptation in the embodiments of this application.

[0069] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0070] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0071] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for customizing road lighting strategies based on interface semantic self-adaptation, characterized in that, Applied to edge-side intelligent execution agents, the methods include: Send a version query request carrying the current version number of the local lighting system to the cloud-based centralized knowledge base, receive the interface semantic description corresponding to the current version number returned by the cloud-based centralized knowledge base and load it into the local cache. The interface semantic description includes the calling rules, parameter constraints and device influence domain of each interface of the lighting system. When a user's lighting strategy generation request is received, the lighting strategy generation request includes the strategy application scenario and optimization goal. Based on the lighting strategy generation request, the interface call rules and parameter constraints of the lighting system are obtained, and the corresponding multi-source operation data is obtained based on a preset set of decision factors according to the strategy application scenario. The AI ​​big model is invoked to identify the application scenarios and optimization goals of the strategy. Based on the identification results, the corresponding interface semantic description is matched from the local cache. The multi-source running data is then input into the AI ​​big model to obtain multiple candidate lighting strategies output by the AI ​​big model. The quantitative operation indicators and visual preview information of each candidate lighting strategy are pushed to the user terminal. In response to the user's target strategy selection operation, the strategy management interface of the lighting system is called according to the interface semantic description in the local cache. The security constraints of strategy switching are verified. After the constraints are met, the target strategy is added or switched through the strategy management interface. Monitor the actual operational data of the target strategy, compare the deviation between the predicted and actual operational indicators, and dynamically adjust the strategy parameters to form an iterative closed loop.

2. The method according to claim 1, characterized in that, The step of obtaining corresponding multi-source operational data based on a preset set of decision factors according to the application scenario of the strategy includes: The application scenario of the strategy is analyzed. If the application scenario of the strategy does not specify a specific area or road segment, the scope of application selection option is pushed to the user terminal so that the user can specify the scope of application of the strategy. Metadata of each area or road segment within the scope of the policy is retrieved from the local private data storage unit. The metadata includes the number of light poles, equipment online rate, road grade, and historical operation data. The system retrieves the planned light-on / off times from the local cache, calls the weather data interface to obtain real-time weather data for each area, and retrieves pedestrian / vehicle traffic data for each area at the hourly granularity from the local private data storage unit to construct a dataset that includes multiple decision factors such as planned light-on / off times, illuminance, weather, and pedestrian / vehicle traffic. The various decision factors are quantified and assigned values, and weighted scores are calculated according to preset weight coefficients. The weighted scores are then added to the multi-source running data, and the sum of the weight coefficients is one.

3. The method according to claim 2, characterized in that, The step of matching the corresponding interface semantic description from the local cache based on the recognition result, and inputting the multi-source runtime data into the AI ​​big model to obtain multiple candidate lighting strategies output by the AI ​​big model specifically includes: The weighted scoring results from the multi-source operational data are combined with the strategy application scenario and optimization objective to generate strategy prompts. The prompts are then input into the AI ​​big model to obtain candidate lighting strategies, which include dimming ratio parameters for each time period. The preset dimming ratio lower limit parameter is obtained from the interface semantic description in the local cache. For each dimming ratio parameter in each time period of each candidate lighting strategy, the dimming ratio lower limit parameter is compared with the dimming ratio lower limit parameter to generate a corrected candidate lighting strategy. The rated luminous flux of the lighting system and the road surface reflectance are obtained based on the interface semantic description in the local cache. Combined with the weather visibility coefficient in the multi-source operation data, the predicted road surface illuminance of each modified candidate lighting strategy at different time periods is calculated. Based on the energy consumption data of the currently effective strategy, the expected energy saving rate of each modified candidate lighting strategy is calculated. The compliance illuminance threshold is obtained based on the interface semantic description in the local cache. The compliance of the predicted road surface illuminance of each corrected candidate lighting strategy is determined based on the compliance illuminance threshold. The compliance status of each strategy in each time period is marked. The corrected dimming ratio parameter, predicted road surface illuminance, expected energy saving rate and compliance status are correlated and used as the output data source of the quantitative operation index.

4. The method according to claim 1, characterized in that, The step of calling the lighting system's policy management interface based on the interface semantic description in the local cache, verifying the security constraints of policy switching, and then adding or switching the target policy through the policy management interface after the constraints are met, specifically includes: Retrieve the currently active system-planned light-on / off times from the local cache and determine if the current system time falls within the light-on period; If the current system time is during the lighting period, the automatic strategy switching will be refused, and a manual operation prompt and risk warning information will be pushed to the user terminal. If the current system time is during the non-lighting period, a secondary confirmation request will be sent to the user terminal. The secondary confirmation request includes the expected energy saving rate of the target strategy and a switching risk warning. After receiving a positive response from the user, the instruction set of the target policy is preloaded according to the interface semantic description in the local cache, and the device connectivity of the policy management interface is verified. If the verification passes, a switching instruction is issued; if the verification fails or no device confirmation is received within a timeout, the policy is automatically rolled back to the original policy and the reason for the failure is recorded. After a successful policy switch, an operation audit log is generated. The audit log includes the operation subject identifier, operation type, operation content description, operation timestamp, and associated policy version number. The audit log is then stored in the local audit database.

5. The method according to claim 1, characterized in that, After obtaining the corresponding multi-source operational data based on a preset set of decision factors according to the application scenario of the strategy, the method further includes weather difference verification and control mode generation, specifically including: Call the weather data interface to obtain the future time period weather data of each region within the scope of the strategy. The weather data includes weather type, visibility coefficient and precipitation probability. Traverse each region and calculate the weather difference value between any two regions. If the weather difference value between any two regions exceeds the preset threshold, push the weather difference prompt and strategy splitting suggestion to the user terminal. Based on the weather data of each region, candidate control modes corresponding to each region are generated. The control modes include a first mode and a second mode. The first mode is a light control-assisted mode that triggers the switching on and off of lights by illuminance within the light control buffer window, based on the system's planned switching on and off time. The second mode is a dual-effect mode that forces the lights to turn on within the system's planned switching on and off time range and triggers the switching on and off of lights by illuminance outside the planned time range. The interface semantic description in the local cache is read to obtain the deployment status of the illuminance collector. If the deployment status indicates that the illuminance collector has been deployed, the edge-side intelligent execution agent will use the first mode or the second mode as the control mode of the candidate strategy, and set the light-on trigger threshold and the light-off trigger threshold according to the illuminance threshold parameters stored in the interface semantic description. If the deployment status indicates that no illuminance collector has been deployed, the light control buffer window of the first mode is extended from the first duration to the second duration, and the second mode is switched to a time control mode that relies entirely on the system's scheduled light switching time to execute the light switching.

6. The method according to claim 1, characterized in that, After receiving the interface semantic description corresponding to the current version number returned by the cloud-based centralized knowledge base and loading it into the local cache, the process also includes incremental knowledge updates, specifically including: Upon receiving an update notification pushed by the cloud-based centralized knowledge base, an incremental update query request is sent to the cloud-based centralized knowledge base. The incremental update query request carries the version identifier of the current interface semantic description in the local cache. The system receives an incremental difference data packet returned by the cloud-based centralized knowledge base. The incremental difference data packet is generated by the cloud-based centralized knowledge base after comparing the version identifier with the latest version stored in the cloud. The incremental difference data packet contains a semantic description of the change interface of the latest version relative to the version identifier. The semantic description of the change interface is accompanied by a change type tag. The change type tag is used to indicate adding an interface, modifying an interface, or deleting an interface. If the change type label is "Add Interface" or "Modify Interface", the corresponding change interface semantic description will be added to or replaced in the local cache for the corresponding version number of the interface semantic description set. If the change type label is "Delete Interface", the corresponding interface in the local cache will be marked as obsolete and removed from the interface semantic description set. After completing the incremental merging, the version identifier of the locally cached interface semantic description is updated to the version identifier of the latest version. When a user's lighting policy generation request is received subsequently, the interface matching and invocation are automatically performed based on the updated interface semantic description.

7. The method according to claim 1, characterized in that, After the constraints are met and the target policy is added or switched through the policy management interface, the process also includes policy effect verification and intelligent rollback, specifically including: After the target strategy is switched and takes effect, a preset effect verification period is started. During the effect verification period, actual operation data during the operation of the target strategy is collected at a first acquisition frequency higher than the conventional monitoring frequency. The actual operation data includes real-time energy consumption data of each loop and real-time illuminance data of each illuminance sensor location. The actual operating data collected during the effect verification period is compared with the predicted operating indicators on a time-by-time basis. The actual energy consumption deviation rate and actual illuminance deviation value for each time period are calculated. If the actual illuminance deviation value is negative and lower than the compliance illuminance threshold, the deviation type is marked as a safety risk deviation. If the actual energy consumption deviation rate is positive and the actual illuminance deviation value does not exceed the compliance illuminance threshold, the deviation type is marked as an abnormal energy consumption deviation. If the deviation type is a security risk deviation, an automatic rollback is triggered, a security alarm and an automatic rollback notification are pushed to the user terminal, and the policy management interface of the lighting system is called to switch back to the original policy according to the interface semantic description in the local cache. If the deviation type is an energy consumption abnormal deviation and the deviation rate exceeds the preset energy consumption rollback threshold, an energy consumption abnormality prompt and rollback suggestion are pushed to the user terminal, and the rollback is executed in response to the user's confirmation operation. If no rollback is triggered within the effect verification period, the edge-side intelligent execution agent will associate the actual running data within the effect verification period with the corresponding predicted running indicators and the actual adopted strategy parameters and store them in the local audit database as historical reference data. If a rollback is triggered, the rollback event and the reason for the rollback will be recorded in the audit log, and the reactivation of the target strategy will be suspended until a manual confirmation instruction from the user is received.

8. A computer system comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the steps of the method according to any one of claims 1-7.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1-7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1-7.

Images