Illumination equipment distributed cooperative control method based on Internet of Things operating system

Abstract

The invention belongs to the technical field of intelligent control and the Internet of Things, and particularly relates to a distributed cooperative control method for lighting equipment based on an operating system of the Internet of Things. The distributed cooperative control of the lighting equipment is converted from a traditional mode of application layer protocol + centralized server to a mode of operating system kernel-level service + distributed peer-to-peer cooperation, and compared with a common centralized control scheme (such as a typical intelligent street lamp cloud platform architecture) based on an MQTT / CoAP protocol connection cloud platform in the prior art, the distributed cooperative control of the lighting equipment is improved. According to the scheme, the dependence on the central server is eliminated, the single-point fault risk is avoided, meanwhile, kernel-level abstraction of the service intention is achieved through the cooperation mode descriptor and the global cooperation registry, and control logic is not separated from network resource management any more.

Description

Technical Field

[0001] This invention belongs to the field of intelligent control and Internet of Things (IoT) technology, specifically relating to a distributed collaborative control method for lighting equipment based on an IoT operating system. Background Technology

[0002] The inventors discovered that in existing technologies, the collaborative control of lighting equipment mostly adopts centralized control or application-layer distributed protocols based on fixed rules. The former suffers from single-point failure and communication bottlenecks, while the latter suffers from a disconnect between its control logic and the underlying network resource scheduling. As a result, in dynamic and complex IoT environments, the real-time performance, reliability, and energy efficiency of collaborative commands cannot be guaranteed. Specifically, when collaborative events (such as linked dimming and dynamic tracking) are triggered, network congestion causes command delays or loss. Furthermore, control algorithms (such as consensus algorithms and federated learning) cannot obtain deterministic support from the network layer during iteration, resulting in slow convergence and consequently, low overall system energy efficiency. Summary of the Invention

[0003] This invention addresses the problems existing in the prior art by providing a distributed collaborative control method for lighting devices based on an Internet of Things (IoT) operating system. The solution effectively solves the problems existing in the prior art.

[0004] To achieve the above objectives, the technical solution adopted by the present invention is as follows: A distributed collaborative control method for lighting devices based on an IoT operating system, which runs on the processor of the lighting device, wherein the kernel of the IoT operating system integrates a collaborative control service framework, the method comprising: Step 1: The application used to implement the collaborative control function of lighting equipment registers the collaborative control intent with the operating system kernel through the interface provided by the collaborative control service framework, and generates and stores the collaborative mode descriptor in the kernel's global collaborative registry; Step 2: When the application triggers a collaborative event, the scheduler of the collaborative control service framework executes a deterministic scheduling algorithm based on the collaborative mode descriptor of the event and the current IoT operating system state to generate a transmission plan that includes precise transmission timing and communication parameters. Step 3: The cooperative control service framework configures the wireless communication hardware and sends data packets at a determined time according to the transmission plan. The header of the data packet carries a cooperative event identifier obtained from the cooperative mode descriptor. The receiving party's cooperative control service framework queries the global cooperative registry based on the cooperative event identifier in the received packet and directly triggers the corresponding application layer processing function. Step 4: Monitor the performance of collaborative communication based on the collaborative control service framework, and dynamically adjust the scheduling strategy and communication parameters.

[0005] Furthermore, the deterministic scheduling algorithm specifically performs the following processing steps: based on the quality of service requirements in the cooperative mode descriptor and the network status information of the current IoT operating system, it performs conflict detection and resource reservation by accessing the global resource planning bitmap, and generates a transmission plan; wherein, the global resource planning bitmap uses time slots and communication channels as two-dimensional indexes to identify the reservation status of corresponding resources in future time windows; the transmission plan includes absolute transmission time, physical communication channel, transmission power, maximum retransmission count, and media access control flags.

[0006] Furthermore, the cooperative control service framework is driven by a high-precision hardware timer. At the absolute transmission moment, a timer interrupt is triggered. The transmission plan is obtained from the transmission queue to be executed through the timer interrupt service routine, and atomic hardware configuration is performed to send the data packet. After receiving the data packet, the cooperative control service framework of the receiver extracts the cooperative event identifier through the receive interrupt service routine. Using the cooperative event identifier as the key, the receiver queries the global cooperative registry to obtain the application callback function pointer and user context pointer in the cooperative mode descriptor. The receiver then directly triggers the application layer processing function through the kernel-to-user space event uploading mechanism, bypassing the user space network protocol stack.

[0007] Furthermore, the dynamic adjustment includes the following processing steps: Online fine-tuning of scheduling strategy: When the timeout rate corresponding to a certain collaborative event identifier exceeds a preset threshold, an urgency compensation factor is added to the collaborative mode descriptor corresponding to the collaborative event identifier. In subsequent scheduling decisions, the business priority is combined with the urgency compensation factor to calculate the final scheduling priority. Channel selection optimization: When a significant increase in the channel conflict rate of a certain cooperative event identifier service plan is detected, the quality score of that channel in the deterministic scheduling algorithm is reduced, so that subsequent scheduling will prioritize other channels with higher quality scores; Adaptive transmit power: The transmit power in the transmit plan is dynamically fine-tuned based on the received signal strength fed back by the receiving device or the link quality detected by the network.

[0008] Furthermore, the dynamic adjustment also includes anomaly detection and system-level recovery, specifically: When the number of consecutive communication failures of a collaborative link corresponding to a certain collaborative event identifier exceeds a preset security threshold, the collaborative service flow is determined to be abnormal. The monitoring thread sends an internal cleanup command to the scheduler to forcibly remove the resource occupancy markers that were reserved but invalidated in the global resource planning bitmap for abnormal business flows. The system event is sent to the application that registered the collaborative event identifier through the asynchronous notification interface provided by the collaborative control service framework, so as to trigger the application layer recovery logic.

[0009] Furthermore, the application initiates collaborative service registration by calling the application programming interface provided by the collaborative control service framework. The input parameters of the application programming interface include: a globally unique collaborative event identifier, a collaborative mode, a pointer to a service quality parameter structure, an application layer callback function pointer, and a user context pointer.

[0010] Furthermore, the processor executes a system call to enter kernel mode from user mode, and the registration service routine of the cooperative control service framework performs parameter verification and copying, kernel dynamic memory allocation to create the cooperative mode descriptor, inserts the cooperative mode descriptor into the global cooperative registry with the cooperative event identifier as the key, and returns the registration result to the application.

[0011] An electronic device includes a memory, a processor, and a computer program stored in the memory and running on the memory. When the processor executes the program, it implements the above-described distributed collaborative control method for lighting devices based on an Internet of Things (IoT) operating system.

[0012] A non-transitory computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned distributed collaborative control method for lighting devices based on an Internet of Things (IoT) operating system.

[0013] Compared with the prior art, the advantages and positive effects of the present invention are as follows: (1) The present invention provides a distributed collaborative control method for lighting devices based on an Internet of Things operating system. This method transforms the distributed collaborative control of lighting devices from the traditional “application layer protocol + centralized server” mode to the “operating system kernel-level service + distributed peer-to-peer collaboration” mode by integrating a collaborative control service framework in the kernel. Compared with the centralized control schemes (such as the typical smart street light cloud platform architecture) that commonly connect to cloud platforms based on MQTT (Message Queuing Telemetry Transport) / CoAP (Constrained Application Protocol) protocols in the prior art, the present invention eliminates the dependence on the central server and avoids the risk of single point of failure. At the same time, the kernel-level abstraction of business intent is realized through “collaborative mode descriptor” and “global collaborative registry”, so that the control logic is no longer separated from network resource management.

[0014] (2) Considering that in the existing technology, application layer distributed protocols (such as ZigBee Light Link and Thread Group's lighting control protocol) usually express QoS (Quality of Service) requirements as application layer parameters, while the actual network resource scheduling is decided independently by the underlying MAC / PHY layer, there is a semantic gap between the two. The solution described in this invention directly accesses the "global resource planning bitmap" through the "deterministic scheduling algorithm" and transforms the QoS requirements such as "maximum tolerable delay" and "service priority" declared by the application layer into specific resource reservation decisions such as "absolute transmission time" and "physical communication channel", thereby realizing cross-layer collaboration. Compared with deterministic network technologies such as TSCH (Time Slotted Channel Hopping) which only provide static time slot allocation, the scheduler in the solution described in this embodiment can perform dynamic resource arbitration based on real-time network status (e.g., channel idleness, RSSI (Received Signal Strength Indicator), LQI (Link Quality Indicator)), which effectively improves resource utilization while ensuring determinism.

[0015] (3) Considering that the lighting control instructions in the prior art usually need to be encapsulated through a complete protocol stack of “application layer → transport layer → network layer → MAC layer → physical layer”, and then decapsulated by the receiving end, each layer needs to introduce buffer, queue and context switching overhead. The solution described in this embodiment achieves microsecond-level precision control of the sending time through “high-precision hardware timer” and “atomic hardware configuration”. By bypassing the protocol stack through “kernel-level event identifier lookup table” and “direct callback trigger”, the event distribution delay is reduced from millisecond level to microsecond level. Through deterministic timing and zero-copy distribution, sufficient delay margin is left for multi-hop cascading. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below: Figure 1 This is a flowchart of the distributed collaborative control method for lighting devices based on an Internet of Things operating system as described in this embodiment of the invention; Figure 2 This is a flowchart illustrating the dynamic adjustment process described in this embodiment of the invention. Figure 3 This is a flowchart illustrating the anomaly detection and system-level recovery process described in this embodiment of the invention. Figure 4 This is a schematic diagram of an electronic device structure according to an embodiment of the present invention. Detailed Implementation

[0017] To better understand the above-mentioned objectives, features and advantages of the present invention, the present invention will be further described below in conjunction with the accompanying drawings and embodiments.

[0018] Numerous specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways than those described herein, and therefore the invention is not limited to the specific embodiments disclosed in the following specification.

[0019] Example 1 In one or more embodiments, such as Figure 1 As shown, this embodiment provides a distributed collaborative control method for lighting devices based on an Internet of Things (IoT) operating system. The method runs on the processor of the lighting device, and the kernel of the IoT operating system integrates a collaborative control service framework. The method includes: Step 1: The application used to implement the collaborative control function of lighting equipment registers the collaborative control intent with the operating system kernel through the interface provided by the collaborative control service framework, and generates and stores the collaborative mode descriptor in the kernel's global collaborative registry; Step 2: When the application triggers a collaborative event, the scheduler of the collaborative control service framework executes a deterministic scheduling algorithm based on the collaborative mode descriptor of the event and the current IoT operating system state to generate a transmission plan that includes precise transmission timing and communication parameters. Step 3: The cooperative control service framework configures the wireless communication hardware and sends data packets at a determined time according to the transmission plan. The header of the data packet carries a cooperative event identifier obtained from the cooperative mode descriptor. The receiving party's cooperative control service framework queries the global cooperative registry based on the cooperative event identifier in the received packet and directly triggers the corresponding application layer processing function. Step 4: Monitor the performance of collaborative communication based on the collaborative control service framework, and dynamically adjust the scheduling strategy and communication parameters.

[0020] In its specific implementation, the deterministic scheduling algorithm performs the following process: based on the quality of service requirements in the cooperative mode descriptor and the network status information of the current IoT operating system, it performs conflict detection and resource reservation by accessing the global resource planning bitmap, and generates a transmission plan; wherein, the global resource planning bitmap uses time slots and communication channels as two-dimensional indexes to identify the reservation status of corresponding resources in future time windows; the transmission plan includes absolute transmission time, physical communication channel, transmission power, maximum retransmission count, and media access control flags.

[0021] In specific implementation, the cooperative control service framework is driven by a high-precision hardware timer. At the absolute transmission moment, a timer interrupt is triggered. The transmission plan is obtained from the transmission queue to be executed through the timer interrupt service routine, and atomic hardware configuration is performed to send the data packet. After receiving the data packet, the cooperative control service framework of the receiver extracts the cooperative event identifier through the receive interrupt service routine. Using the cooperative event identifier as the key, the receiver queries the global cooperative registry to obtain the application callback function pointer and user context pointer in the cooperative mode descriptor. The receiver then directly triggers the application layer processing function through the kernel-to-user space event uploading mechanism, bypassing the user space network protocol stack.

[0022] In practice, the dynamic adjustment includes the following processing steps: Online fine-tuning of scheduling strategy: When the timeout rate corresponding to a certain collaborative event identifier exceeds a preset threshold, an urgency compensation factor is added to the collaborative mode descriptor corresponding to the collaborative event identifier. In subsequent scheduling decisions, the business priority is combined with the urgency compensation factor to calculate the final scheduling priority. Channel selection optimization: When a significant increase in the channel conflict rate of a certain cooperative event identifier service plan is detected, the quality score of that channel in the deterministic scheduling algorithm is reduced, so that subsequent scheduling will prioritize other channels with higher quality scores; Adaptive transmit power: The transmit power in the transmit plan is dynamically fine-tuned based on the received signal strength fed back by the receiving device or the link quality detected by the network.

[0023] In practice, the dynamic adjustment also includes anomaly detection and system-level recovery, specifically: When the number of consecutive communication failures of a collaborative link corresponding to a certain collaborative event identifier exceeds a preset security threshold, the collaborative service flow is determined to be abnormal. The monitoring thread sends an internal cleanup command to the scheduler to forcibly remove the resource occupancy markers that were reserved but invalidated in the global resource planning bitmap for the abnormal service flow. The system event is sent to the application that registered the collaborative event identifier through the asynchronous notification interface provided by the collaborative control service framework, so as to trigger the application layer recovery logic.

[0024] In specific implementation, the application initiates collaborative service registration by calling the application interface provided by the collaborative control service framework. The input parameters of the application interface include: a globally unique collaborative event identifier, a collaborative mode, a pointer to a service quality parameter structure, an application layer callback function pointer, and a user context pointer.

[0025] In a specific implementation, the processor executes a system call to enter the kernel mode from the user mode. The registration service routine of the cooperative control service framework performs parameter verification and copying, kernel dynamic memory allocation to create the cooperative mode descriptor, inserts the cooperative mode descriptor into the global cooperative registry with the cooperative event identifier as the key, and returns the registration result to the application.

[0026] It should be noted here that: In the scheme described in this embodiment, the collaborative control service framework is a basic service component integrated into the kernel space of the IoT operating system. It resides in the intermediate layer between user-space applications and the underlying network protocol stack and device drivers. This framework is loaded as a kernel module and runs directly in kernel space. It provides collaborative control services to user-space applications through system call interfaces, and simultaneously interacts with high-precision hardware timer drivers, network device drivers, and memory management modules through internal kernel interfaces. Specifically, the collaborative control service framework's position in the system architecture is as follows: Upward, it receives collaborative control requests from user-space components such as lighting control applications and scene management services through standard system call interfaces (such as coop_register() and coop_trigger_event()); downward, it bypasses the traditional user-space network protocol stack and directly calls the data packet sending interface of the network device driver to achieve low-latency delivery of control commands.

[0027] In its implementation, the scheduler, as the core execution component of the collaborative control service framework, is embedded within the framework as a kernel thread, sharing the same kernel address space. The scheduler is not an independent system process or user-mode service, but a dedicated kernel scheduling thread created and managed by the collaborative control service framework, its lifecycle tied to the framework. The scheduler obtains the necessary scheduling information by accessing the global collaborative registry and global resource planning bitmap maintained by the framework, and generates a transmission plan based on a deterministic scheduling algorithm. Simultaneously, the scheduler collaborates with the monitoring thread within the framework, receiving resource cleanup instructions and timeout feedback from the monitoring thread, and dynamically adjusting the scheduling strategy. This embedded design allows the scheduler to directly manipulate kernel data structures, avoiding the context switching overhead between user mode and kernel mode, ensuring that the entire path from scheduling decision to instruction issuance is in kernel mode, thereby achieving microsecond-level deterministic event distribution. For ease of understanding, the following example illustrates a street light system (including smart street light A, smart street light B, smart street light C, etc.) deployed along a road in a park. Each smart street light runs an IoT operating system integrated with the aforementioned collaborative control service framework. When pedestrians enter a preset area at night (i.e., a preset range centered on a smart street light), the distributed collaborative control of the smart street lights enables a guiding effect where the entire street light system lights up all at once with a smooth brightness transition. Specifically: In specific implementation, step 1: The application used to implement the collaborative control function of lighting equipment registers the collaborative control intent with the operating system kernel through the interface provided by the collaborative control service framework, generates and stores the collaborative mode descriptor in the kernel's global collaborative registry, and specifically performs the following processing: Step 101: The application layer (i.e., the application) initiates a registration request. Specifically, the application located locally on smart street light A (e.g., a light guidance control application) initiates collaborative service registration during the initialization phase by calling the application programming interface (API function) provided by the collaborative control service framework. For example, the following API function can be used: coop_register(int event_id, enum coop_mode mode, struct qos_profile qos, coop_callback_t callback, void user_ctx) in: event_id is a globally unique collaborative event identifier. For example, it can be defined as: EVENT_LIGHT_GUIDANCE with a value of 0x0001. All smart streetlights (i.e., smart streetlights A, B, and C) on the same business chain use the same event_id.

[0028] The mode is the cooperative mode. If it is specified as COOP_MODE_CASCADE (cascade mode), it means that the event will be triggered sequentially along the device.

[0029] `qos` is a pointer to a structure containing service quality parameters. This structure defines the baseline requirements for this collaboration, for example: struct qos_profile { uint32_t max_latency_us; / / Maximum tolerable latency, such as 50 milliseconds; uint8_t reliability; / / Reliability requirement, such as 99%; uint16_t min_bandwidth_bps; / / Minimum bandwidth required, such as 150bps; uint8_t priority; / / Business priority, such as 7 (range 0-7, 7 is the highest)}; `callback` is a pointer to an application-layer callback function. The kernel will call this function when the device receives a coordination event.

[0030] user_ctx is a user context pointer used to pass application state during callbacks.

[0031] Step 102: The kernel creates and stores the co-mode descriptor. Specifically, the processor executes the aforementioned system call, transitioning from user mode to kernel mode, and the registration service routine of the coordinated control service framework performs the following sub-operations: (1) Parameter validation and copying: Securely copy and validate all incoming parameters from user space; (2) Memory allocation: In the kernel's dynamic memory pool, a block of memory is allocated to create an instance of the struct coop_mode_descriptor structure, which includes at least the following fields: struct coop_mode_descriptor { uint32_t event_id; / / Co-event identifier enum coop_mode mode; / / Co-op mode struct qos_profile qos; / / QoS requirements coop_callback_t app_callback; / / Pointer to the user-space callback function void user_context; / / User context struct list_head list; / / Linked list nodes used for accessing the registry atomic_t ref_count; / / Reference count}; (3) Global Registration: Using event_id as the key, the newly created descriptor is inserted into the global collaborative registry. The global collaborative registry uses a hash table located in the kernel data segment, and the insertion process is as follows: Calculate the hash value: hash = event_id % HASH_SIZE, and add the descriptor to the linked list of the corresponding hash bucket, where HASH_SIZE is the size of the hash table.

[0032] (4) State synchronization and return: Update the bitmap in the kernel that represents the system's collaborative business state, and then return the memory address of the descriptor (or a secure handle) as the registration result to the user space application (i.e. the aforementioned light boot control application).

[0033] Ultimately, the lighting guidance service on smart street light A completes data archiving in the kernel, and similar applications on smart street lights B, C, and other devices execute the same registration process. The global collaborative registry becomes the core bridge connecting network packets (carrying event_id) and local processing logic (app_callback).

[0034] In one or more embodiments, the application is a functional software module for implementing specific lighting collaborative control. Its core function is to transform upper-layer, scenario-specific collaborative business logic (e.g., path guidance, area synchronization) into standardized operation instructions conforming to the collaborative control service framework specification in the kernel, and to serve as the final execution endpoint of this business logic. The interaction between the application and the collaborative control service framework follows a standardized paradigm of "declaring intent – ​​triggering event – ​​responding to execution," thus forming a complete collaborative control closed loop. Specifically, the main functional implementations of the application include: (1) Standardized declaration of collaborative intent: When an application initiates its collaborative control service, it needs to provide the collaborative control service framework with a set of standardized collaborative control intent parameters that can be quantified and evaluated by the kernel. These collaborative control intent parameters include, but are not limited to: Collaborative Event Identifier: A global symbol used to uniquely identify a type of collaborative service (such as "People's Bank Guidance").

[0035] Collaborative behavior patterns: describe the propagation and processing methods of collaborative events, such as "unicast control", "broadcast synchronization" or "sequential cascading triggering".

[0036] Quality of Service Requirements: Define the performance requirements of the communication system for this collaborative service in the form of quantitative indicators (such as maximum allowable latency, minimum reliability requirements, and service priority).

[0037] Event response entry point: Provides a reference to its own internal processing routine so that the kernel can directly call the routine when it receives the corresponding cooperative event.

[0038] (2) Standardized triggering function for collaborative events: When the application's internal logic (such as sensor data processing logic, timing logic, or upper-layer strategy logic) determines that a collaborative action needs to be initiated, it sends a standardized trigger request to the collaborative control service framework. The trigger request includes the corresponding collaborative event identifier and specific control parameter data related to this event (e.g., target brightness, target color temperature, and next-hop device identifier).

[0039] (3) Local execution function of cooperative instructions: When the kernel framework (i.e., the collaborative control service framework) locates an application registered with the corresponding collaborative event identifier on the device based on the received network data packet, it will directly call the application's pre-registered response entry point and pass the received control parameter data. The application will then randomly execute its internal device control logic to complete specific physical operations, including but not limited to adjusting the brightness of the light source, changing the color, and switching on / off states.

[0040] For ease of understanding, the following section provides a detailed explanation of the interaction mechanism between the application and the kernel framework, broken down into stages: Initialization and intent registration phase: Before starting its collaborative services, the application first accesses the dedicated programming interface provided by the collaborative control service framework through the standard system call interface provided by the IoT operating system, and specifically performs the following tasks: 1) Submit registration parameters: The application submits a registration information package to the framework, which includes its collaboration event identifier, collaboration mode, quality of service requirements, and references to local response functions.

[0041] 2) Kernel Creation Management Unit: The kernel service portion of the framework receives this information packet, verifies and parses it. Subsequently, based on this information, the kernel dynamically creates and initializes an internal data structure called "Cooperation Mode Descriptor" in the protected kernel memory space. This structure is the sole internal basis for the kernel to manage and schedule this cooperative service, and it fully records all intent parameters declared by the application.

[0042] 3) Establishing a global mapping: The kernel stores this cooperative mode descriptor, indexed by the cooperative event identifiers it contains, in a global data structure (i.e., the "global cooperative registry") that can be quickly queried by all relevant kernel modules. This step signifies that the cooperative service has been formally accepted and managed by the kernel, and a defined contractual relationship has been established between the application and the kernel for this service.

[0043] Runtime and event triggering phase: During business operations, the interaction between the application and the kernel is time-driven, and specifically includes the following processes: 1) Event Trigger Request: When the application's business logic meets preset conditions (e.g., ambient light sensor value is below a preset threshold, signal is received from human body sensor, or internal timer expires), the application initiates a trigger request for a collaborative event through the dedicated programming interface provided by the collaborative control service framework. The trigger request includes, but is not limited to, the triggered collaborative event identifier and the application layer data payload related to this event.

[0044] 2) Request Submission to Kernel Queue: The framework interface transmits the triggered request and its payload data to the kernel's pending event queue in an asynchronous, non-blocking manner. It should be noted that, through the design of the pending event queue, the application's execution thread will not be blocked while waiting for communication to complete after this call, thus effectively ensuring the application's responsiveness.

[0045] 3) Kernel Takeover of Subsequent Processes: Next, the handling of the aforementioned collaborative events is entirely handled by the kernel framework. Specifically, the kernel scheduler finds the corresponding collaborative mode descriptor from the global collaborative registry based on the current collaborative event identifier, performs resource scheduling and planning based on the service quality requirements in the descriptor and the real-time system status (corresponding to step 2 above), and executes communication at the precise time determined by the planning (corresponding to step 3 above).

[0046] Response and instruction execution phase: When the current device acts as the receiver of a collaborative event, its application participates in the processing by being invoked, specifically including: 1) Direct distribution by the kernel: After the current device understands that it has received a data packet, it extracts the cooperative event identifier in the header of the data packet through the kernel driver layer. The kernel queries the global cooperative registry through the cooperative event identifier, and directly locates the application that registered the identifier and the response function reference without going through the user space network protocol stack.

[0047] 2) Calling the application execution unit: The kernel uses the efficient communication mechanism (such as signals, events or dedicated data channels) provided by the IoT operating system between kernel mode and user mode to directly pass the received data payload along with context information to the pre-registered response function of the application.

[0048] 3) Perform local physical control: After the application's response function is activated, it immediately parses the incoming data payload and converts it into specific control instructions for the device's lighting actuators (such as LED drivers and dimming circuits) (e.g., setting the PWM duty cycle to adjust brightness, or sending DALI (Digital Addressable Lighting Interface) instructions to change color temperature), thereby completing the implementation of collaborative control at the physical level.

[0049] In specific implementation, step 2: When the application triggers a collaborative event, the scheduler of the collaborative control service framework executes a deterministic scheduling algorithm based on the collaborative mode descriptor of the event and the current IoT operating system state to generate a transmission plan including precise transmission timing and communication parameters. Specifically, this includes the following processing steps: When a coordinated event is triggered, the kernel scheduler performs immediate arbitration and planning of global resources to ensure deterministic instruction transmission. Specifically: Step 201: Application triggers event When the sensor on smart street light A detects a pedestrian entering its illumination range, the application determines to trigger a guidance event, which calls the interface of the cooperative control service framework: coop_trigger_event(int event_id, void data, size_t len, uint32_ttimeout), Among them, event_id is EVENT_LIGHT_GUIDANCE, data contains the control parameters for guiding the service (such as target brightness, next-hop device identifier, etc.), and timeout is the waiting timeout threshold for this triggered operation.

[0050] The processor executes the aforementioned system call, transitioning from user mode to kernel mode. Specifically, the event-triggered service routine creates an event-triggered request (e.g., encapsulated as a kernel data structure named `struct event_request`). This structure encapsulates all information about the current collaborative service instance passed from the application layer, including at least: the collaborative event identifier ID (i.e., `event_id`), and a kernel pointer to the application layer data payload (i.e.,...). The parameters include data, data length (len), trigger event stamp, and application-specified timeout requirement (timeout).

[0051] Step 202: The kernel scheduler makes real-time decisions. The event triggering request (i.e., the struct event_request instance) generated in step 201 is placed into a kernel event queue (e.g., a min-heap, where the top element is the request with the most urgent deadline and the highest business priority) arranged according to the maximum tolerable delay and business priority. Then, it enters the kernel thread (i.e., the scheduler thread) of the collaborative control service framework for scheduling loop. The scheduler thread specifically executes the following processing procedure: (1) Context collection: Retrieve the highest priority event from the kernel event queue to trigger the request; Based on the collaborative event identifier carried in the event trigger request, the global collaborative registry is queried to obtain the corresponding collaborative mode descriptor, thereby determining the collaborative requirements for this event (e.g., maximum tolerable delay of 50 milliseconds, priority level 7). Obtain real-time network status information from the network device driver module, including the current channel idle level, Received Signal Strength Indicator (RSSI), and Link Quality Indicator (LQI). Obtain the system's high-precision global timestamp as the base time for scheduling calculations.

[0052] (2) Conflict detection and resource decision-making: The scheduler accesses a global resource planning bitmap maintained by the kernel. This bitmap uses discrete (time slot, communication channel) two-dimensional indexes, with each bit indicating whether the corresponding resource has been reserved and occupied by other cooperating services within a future time window.

[0053] First, the scheduler reads the QoS requirements associated with the event triggering request, extracts the maximum latency tolerance value and service priority, and queries the global collaborative registry for the current urgency compensation factor of the corresponding service type for the event (dynamically calculated and generated by the PID control algorithm in step 402 based on historical timeout rates). The scheduler sums the maximum latency tolerance value with the current system timestamp to obtain the absolute deadline, and uses the classic earliest deadline first (EDF) algorithm to calculate the final scheduling priority of the event. The calculation formula is as follows: Final scheduling priority = Absolute deadline - α × Business priority - β × Urgency compensation factor; Where α and β are preset normalized weight coefficients; The smaller the final scheduling priority value, the higher the scheduling urgency. The scheduler sorts all the events to be scheduled in the kernel event queue according to the final scheduling priority, ensuring that the top of the queue is always the event that needs to be processed first in the current system. Subsequently, for the queue top event, the scheduler traverses the future available resource windows identified by the global resource planning bitmap and performs conflict detection: for each candidate time slot, the scheduler queries the channel quality score table maintained in step 401 to obtain the quality score of each available channel in the current time slot (this score comprehensively reflects the channel's historical conflict rate, Link Quality Indicator (LQI), and Received Signal Strength Indicator (RSSI), and removes channels with quality scores lower than the preset quality threshold in the QoS requirements; among the candidate resources that pass the quality screening, the scheduler adopts a deterministic resource selection rule—prioritizing the channel with the highest quality score, and if multiple channels have the same quality score, selecting the channel with the smallest channel number—to resolve resource conflicts and ensure the determinism of resource allocation; In one or more embodiments, the sending plan scheme employs a sending plan structure (e.g., named struct tx_schedule), which includes the following data: Absolute transmission time: nanosecond-level precise time point based on a high-precision counter; Physical communication channel: the specific wireless frequency used; Transmit power: Radio frequency transmit power level; Maximum number of retransmissions: The upper limit of retransmissions allowed by the link layer; Media Access Control (MAC) flags: such as whether to require confirmation of receipt, whether to use a priority access mechanism, etc.

[0054] Example: To meet the 50-millisecond end-to-end delay budget of the EVENT_LIGHT_GUIDANCE event, the following decision (i.e., transmission planning scheme) may be made after calculation by the preset scheduling algorithm: 25 milliseconds from the current moment, in the third communication time slot defined by the system, the 15th physical channel will be used to transmit data at a transmit power of 10dBm, and the MAC layer confirmation mechanism will be enabled to ensure reliability.

[0055] (3) Resource reservation and planning: The processor writes the calculated transmission plan (i.e., the transmission plan structure) into a transmission queue to be executed, which is strictly ordered according to the absolute transmission time (through a circular buffer or time wheel). In the global resource planning bitmap, the status of the resource unit to be used by the decision (e.g., time slot 3 and communication channel 15) is set to "reserved", thereby locking the resource and preventing conflicts from other subsequent collaborative events or ordinary network traffic. If a feasible scheduling solution cannot be found within the timeout period specified in the event trigger request due to insufficient resources or conflicts, the request is marked as "scheduling failed". It can be removed from the queue and a timeout error can be returned to the requesting application immediately through the framework interface; or the QoS requirements can be reduced according to the policy (such as business allowance) and the queuing scheduling can be retried.

[0056] In specific implementation, step 3: The cooperative control service framework configures the wireless communication hardware and sends data packets at a determined time according to the transmission plan, wherein the header of the data packet carries a cooperative event identifier obtained from the cooperative mode descriptor; the cooperative control service framework of the receiving party queries the global cooperative registry according to the cooperative event identifier in the received packet and directly triggers the corresponding application layer processing function. The purpose of this step is to ensure that the transmission plan generated in step 2 is executed strictly and reliably at the precise timing of the plan, and that data is distributed to the target application at the receiving end with zero latency, completely bypassing the traditional network protocol stack. Specifically, this includes: Step 301: Precise timing transmission based on the global resource planning bitmap: The transmission action is driven by a high-precision hardware timer according to the absolute transmission timing defined in the transmission planning structure; including: (1) Timed trigger: When the timer count reaches absolute_tx_time_ns (e.g., 25ms in the previous example), a hardware interrupt is generated; (2) Obtain planning and configure hardware: 1) When the timer interrupt service routine (ISR) is triggered, it immediately retrieves the tx_schedule structure that is due at this moment from the head of the pending send queue; 2) Atomized hardware configuration: The processor executes a series of fast, deterministic register write operations, strictly configuring the wireless communication hardware according to the parameters in tx_schedule. Set the physical channel: for example, set it to channel 15; Set the transmit power: for example, set it to 10dBm; Set MAC layer control flags: for example, enable ACK; (3) Data packet assembly and triggering transmission: A complete physical layer data frame is constructed in the kernel buffer, wherein the data frame header contains a cooperative event identifier (i.e., event_id, EVENT_LIGHT_GUIDANCE in the scheme described in this embodiment) determined by the original event triggering request, and the frame payload contains the data payload transmitted by the application layer in step 201. The constructed data frame is loaded into the transmit first-in-first-out (FIFO) buffer of the wireless transceiver through the direct memory access (DMA) mechanism. Finally, a hardware command is triggered, and the wireless transceiver begins transmitting data packets on the specified channel at the specified power.

[0057] Step 302: High-efficiency kernel-level event distribution at the receiving end Assuming that the adjacent smart street light B successfully receives the aforementioned data packet from smart street light A, the wireless hardware of smart street light B generates a reception completion interrupt.

[0058] (1) Data packet reception and preliminary processing: The Receive Terminal Service Routine (ISR) is triggered, which quickly reads data packets from the hardware receive FIFO into the kernel receive buffer. Perform basic integrity checks such as Cyclic Redundancy Check (CRC). If the check passes, extract the Cooperative Event Identifier (i.e., event_id, EVENT_LIGHT_GUIDANCE in the scheme described in this embodiment) from the fixed header position of the data frame.

[0059] (2) Kernel direct event routing: Key table lookup operation: The kernel immediately queries the hash table of the global collaborative registry using the extracted envent_id as the key; Skip the protocol stack and distribute directly: If the table lookup is successful, the kernel directly obtains the corresponding cooperative mode descriptor; From this descriptor, the kernel obtains the pre-registered application callback function pointer (i.e., app_callback) and the user context pointer (i.e., user_context); Instead of passing data packets to the user-space network protocol stack (such as the TCP / IP stack) for layer-by-layer decapsulation, the kernel initiates an efficient "kernel-to-user-space event delivery" mechanism, which can be: The callback request, data payload pointer, and length are encapsulated into a kernel event object and placed into a dedicated inter-process communication (IPC) channel; Alternatively, a dedicated kernel work queue task can be set up for the collaborative event service. This task is responsible for switching to user mode in a safe context and directly invoking the target application's callback function.

[0060] (3) Application layer final execution: The light_guidance_handler function registered in the application is woken up and called by the kernel mechanism. This function executes the corresponding business logic by parsing the incoming data payload, such as controlling the light source of this device to light up to the specified brightness, and preparing to pass the boot event to the next device (such as smart street light C).

[0061] It should be noted that the entire distribution process in the scheme described in this embodiment, from hardware interruption to calling the user-mode callback function, completely avoids the lengthy and uncertain paths of socket reading and writing and protocol stack processing in traditional schemes, and achieves microsecond-level deterministic event distribution.

[0062] In specific implementation, such as Figure 2 and Figure 3 As shown, step 4: monitoring the performance of collaborative communication based on the collaborative control service framework, and dynamically adjusting the scheduling strategy and communication parameters, specifically includes the following processing steps: This step involves constructing a feedback and control closed loop, enabling the system to dynamically adjust its parameters based on actual operating performance data to adapt to changes in the network environment and continuously optimize collaborative control performance.

[0063] Step 401: Collection of Multidimensional Performance Indicators The scheme described in this embodiment periodically activates a low-priority background monitoring thread running in the kernel to collect performance data related to collaborative services across the entire system, including: (1) Business layer statistics: Traverse the global collaboration registry and read its historical performance data from the kernel statistics counter associated with each collaboration mode descriptor, including but not limited to: cumulative number of triggers, number of successful responses, statistical value of communication delay (the average value is used in this embodiment) and number of packet loss or timeouts.

[0064] (2) Network layer status: Obtain statistical information of the physical layer and link layer from the network device driver interface, including but not limited to: historical interference level and collision rate of each channel, average link quality indicator (LQI), hardware error count and received signal strength (RSSI) distribution.

[0065] (3) System resource status: Obtain system-level load information, including but not limited to: CPU utilization of the scheduler thread, hardware interrupt frequency, current depth of the pending send queue, and kernel memory usage.

[0066] The collection of the aforementioned multi-dimensional performance indicators breaks through the monitoring blind spot of the separation of "control and communication" in the existing technology. Existing lighting control systems usually rely on application layer heartbeats or simple statistics (such as SNMP polling) to obtain network status. The sampling period is long and the granularity is coarse, which cannot reflect the real-time information required for microsecond-level scheduling decisions. However, the solution described in this embodiment periodically collects three-dimensional indicators of "business layer statistics - network layer status - system resource status" through a kernel-level "low-priority background monitoring thread", realizing full-stack visualization from application QoS to physical layer interference. It provides deterministic input for online optimization of control algorithms.

[0067] Step 402: Dynamic Parameter Adjustment and Optimization Strategy Based on the obtained performance data and the aforementioned monitoring thread, a preset lightweight adaptive optimization algorithm (in this embodiment, a proportional-integral-derivative (PID) control principle) is used to dynamically adjust the key system parameters. Specifically: (1) Online fine-tuning of scheduling strategy (using business layer statistics; the scheme described in this embodiment mainly utilizes the number of packet losses or timeouts): For a given event_id, when the statistical data within a preset phase shows that the timeout rate exceeds a preset threshold, an urgency compensation factor is added to the collaborative mode descriptor corresponding to the event. For example, in the scheduler decision phase of step 202, when calculating the actual scheduling priority of the event, the business priority is combined with the urgency compensation factor, where the urgency compensation factor is the output of a preset PID algorithm, and its input is the deviation between the recent timeout rate and the expected target. The above settings can enable the event to obtain a more favorable scheduling order in the later resource competition, thereby proactively solving the delay problem.

[0068] (2) Adaptive optimization of communication parameters (using network layer state and system resources): Channel selection optimization: When a significant increase in the collision rate of a channel planned for a certain envent_id service (e.g., channel 15) is detected within a preset phase, the monitoring thread optimizes channel selection by reducing the quality score of that channel within the scheduling algorithm; for example, when performing resource planning for similar events in step 202, the scheduler will select other channels with higher quality scores.

[0069] In practice, a channel quality score table needs to be maintained, which stores the quality score of each channel, and the quality score of each channel can be dynamically adjusted in this step.

[0070] Adaptive transmit power: Based on the RSSI feedback from the receiving device or the link quality detected by the network, the transmit power (i.e., the RF transmit power level) in the transmit planning structure tx_schedule is dynamically fine-tuned. This can achieve energy consumption optimization and overcome instantaneous path loss while ensuring communication reliability.

[0071] The above scheme has the following advantages: Considering that existing lighting energy-saving strategies mostly focus on dimming algorithms (such as adjusting brightness based on ambient light sensors), while neglecting the optimization of communication energy consumption, the scheme described in this embodiment proactively increases service priority when latency deteriorates through "schedule strategy fine-tuning," avoids interfering channels to reduce retransmissions through "channel selection optimization," and minimizes RF power consumption while ensuring link margin through "adaptive transmission power." Compared to the static power configuration or simple channel frequency hopping in existing technologies, the adaptive mechanism in the scheme described in this embodiment can track dynamic environmental changes, achieving Pareto optimality in reliability, real-time performance, and energy efficiency.

[0072] Step 403: Anomaly Detection and System-Level Recovery When the number of consecutive communication failures of a certain cooperating link corresponding to a certain envent_id exceeds the preset security threshold, it is determined that the current cooperating service flow has been interrupted or other abnormalities. By sending an internal cleanup command to the scheduler through the monitoring thread, the resource occupancy markers of all reserved but potentially invalid resources in the global resource planning bitmap of abnormal business flows are forcibly cleared to prevent resource hoarding. Meanwhile, through the asynchronous notification interface provided by the collaborative control service framework, system events are sent to the application that registered the envent_id, and the application can then trigger its application-layer recovery logic based on these system events.

[0073] Example 2 like Figure 4 As shown, this embodiment provides an electronic device, including a memory, a processor, and a computer program stored in the memory and running on it. When the processor executes the program, it implements the above-described distributed collaborative control method for lighting devices based on an Internet of Things operating system.

[0074] Example 3 A non-transitory computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned distributed collaborative control method for lighting devices based on an Internet of Things (IoT) operating system.

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

Claims

1. A distributed collaborative control method for lighting equipment based on an Internet of Things (IoT) operating system, characterized in that, The processor running on the lighting device integrates a collaborative control service framework in the kernel of the IoT operating system, and the method includes: Step 1: The application used to implement the collaborative control function of lighting equipment registers the collaborative control intent with the operating system kernel through the interface provided by the collaborative control service framework, and generates and stores the collaborative mode descriptor in the kernel's global collaborative registry; Step 2: When the application triggers a collaborative event, the scheduler of the collaborative control service framework executes a deterministic scheduling algorithm based on the collaborative mode descriptor of the event and the current IoT operating system state to generate a transmission plan that includes precise transmission timing and communication parameters. Step 3: The cooperative control service framework configures the wireless communication hardware and sends data packets at a determined time according to the transmission plan. The header of the data packet carries a cooperative event identifier obtained from the cooperative mode descriptor. The receiving party's cooperative control service framework queries the global cooperative registry based on the cooperative event identifier in the received packet and directly triggers the corresponding application layer processing function. Step 4: Monitor the performance of collaborative communication based on the collaborative control service framework, and dynamically adjust the scheduling strategy and communication parameters.

2. The distributed collaborative control method for lighting equipment based on an Internet of Things operating system as described in claim 1, characterized in that, The deterministic scheduling algorithm specifically performs the following process: based on the quality of service requirements in the cooperative mode descriptor and the network status information of the current IoT operating system, it performs conflict detection and resource reservation by accessing the global resource planning bitmap, and generates a transmission plan; wherein, the global resource planning bitmap uses time slots and communication channels as two-dimensional indexes to identify the reservation status of corresponding resources in future time windows; the transmission plan includes absolute transmission time, physical communication channel, transmission power, maximum retransmission count, and media access control flags.

3. The distributed collaborative control method for lighting equipment based on an Internet of Things operating system as described in claim 2, characterized in that, The collaborative control service framework is driven by a high-precision hardware timer. At the absolute transmission time, a timer interrupt is triggered. The transmission plan is obtained from the transmission queue to be executed through the timer interrupt service routine, and atomic hardware configuration is executed to send the data packet. After receiving the data packet, the receiving party's collaborative control service framework extracts the collaborative event identifier through the receive interrupt service routine, queries the global collaborative registry with the collaborative event identifier as the key, obtains the application callback function pointer and user context pointer in the collaborative mode descriptor, and directly triggers the application layer processing function through the kernel-to-user space event uploading mechanism, bypassing the user space network protocol stack.

4. The distributed collaborative control method for lighting equipment based on an Internet of Things operating system as described in claim 3, characterized in that, The dynamic adjustment includes the following processing steps: Online fine-tuning of scheduling strategy: When the timeout rate corresponding to a certain collaborative event identifier exceeds a preset threshold, an urgency compensation factor is added to the collaborative mode descriptor corresponding to the collaborative event identifier. In subsequent scheduling decisions, the business priority is combined with the urgency compensation factor to calculate the final scheduling priority. Channel selection optimization: When a significant increase in the channel conflict rate of a certain cooperative event identifier service plan is detected, the quality score of that channel in the deterministic scheduling algorithm is reduced, so that subsequent scheduling will prioritize other channels with higher quality scores; Adaptive transmit power: The transmit power in the transmit plan is dynamically fine-tuned based on the received signal strength fed back by the receiving device or the link quality detected by the network.

5. The distributed collaborative control method for lighting equipment based on an Internet of Things operating system as described in claim 4, characterized in that, The dynamic adjustment also includes anomaly detection and system-level recovery, specifically: When the number of consecutive communication failures of a collaborative link corresponding to a certain collaborative event identifier exceeds a preset security threshold, the collaborative service flow is determined to be abnormal. The monitoring thread sends an internal cleanup command to the scheduler to forcibly remove the resource occupancy markers that were reserved but invalidated in the global resource planning bitmap for abnormal business flows. The system event is sent to the application that registered the collaborative event identifier through the asynchronous notification interface provided by the collaborative control service framework, so as to trigger the application layer recovery logic.

6. The distributed collaborative control method for lighting devices based on an Internet of Things operating system as described in any one of claims 1-5, characterized in that, The application initiates collaborative service registration by calling the application interface provided by the collaborative control service framework. The input parameters of the application interface include: a globally unique collaborative event identifier, a collaborative mode, a pointer to a service quality parameter structure, an application layer callback function pointer, and a user context pointer.

7. The distributed collaborative control method for lighting equipment based on an Internet of Things operating system as described in any one of claims 1-5, characterized in that, The processor executes a system call to enter kernel mode from user mode. The registration service routine of the cooperative control service framework performs parameter verification and copying, kernel dynamic memory allocation to create the cooperative mode descriptor, inserts the cooperative mode descriptor into the global cooperative registry using the cooperative event identifier as the key, and returns the registration result to the application.

8. An electronic device, comprising a memory, a processor, and a computer program stored in the memory and running thereon, wherein the processor executes the program to implement the distributed collaborative control method for lighting devices based on an Internet of Things operating system as described in any one of claims 1-7.

9. A non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the distributed collaborative control method for lighting devices based on an Internet of Things operating system as described in any one of claims 1-7.

Images