Intelligent lighting control system based on multi-protocol dynamic switching and control method thereof

Abstract

The invention relates to the technical field of intelligent lighting control of building automation, and particularly discloses an intelligent lighting control system based on multi-protocol dynamic switching and a control method thereof. The system comprises a lighting controller, a multi-protocol communication module, a protocol arbitration module, a unified state memory, a local logic execution engine and a man-machine interaction interface. According to the method, communication quality of each protocol channel is monitored in real time, a health degree score is calculated, a protocol switching process is dynamically triggered, cross-protocol state synchronization is realized by adopting unified state storage, local control is automatically degraded when a network is abnormal, and state backtracking is completed after the network is recovered. According to the invention, gateway-free intelligent cooperation of multiple protocols of a management layer and a field layer is realized, the real-time consistency of a control state is guaranteed, the reliability and fault-tolerant capability of the system are improved, the operation and maintenance process is simplified, and the system can be widely applied to illumination control scenes of high-end intelligent buildings and has remarkable economic and social benefits.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of intelligent lighting control of building automation, in particular to an intelligent lighting control system based on multi-protocol dynamic switching and a control method thereof. Especially, it relates to an intelligent lighting control system and a control method thereof supporting multi-protocol automatic switching between a management layer and a field layer, real-time synchronization of control states, and autonomous fault-tolerant degradation of network exceptions, which is suitable for heterogeneous protocol integrated lighting scenes of high-end intelligent buildings. BACKGROUND

[0002] With the evolution of intelligent building technology, building automation systems have formed a typical multi-level architecture, in which the management layer is responsible for global monitoring and centralized scheduling, and the field layer is responsible for local control of devices and real-time response. As the core subsystem of building automation, the lighting system needs to access both the standardized integrated protocol of the management layer (such as the BACnet protocol, widely used in BMS centralized management) and the device interconnection protocol of the field layer (such as the KNX protocol, suitable for distributed sensor and actuator networking), in order to balance the efficiency of centralized management and control and the flexibility of local control.

[0003] However, the existing intelligent lighting control system has the following core technical defects in multi-protocol integration application, which seriously restricts the intelligent level and operation reliability of high-end intelligent buildings: 1. Significant protocol heterogeneity coordination obstacles: Existing controllers mostly use the architecture of "single protocol dominance + gateway conversion", and the protocols of the management layer and the field layer need to realize data interaction through a third-party gateway, which not only increases system delay and fault nodes, but also cannot realize dynamic collaborative switching between protocols. When the gateway fails or the network is congested, it is easy to cause control link interruption, which cannot meet the requirements of high-end buildings for control continuity.

[0004] 2. Lack of cross-protocol state synchronization mechanism: In the multi-protocol coexistence scene, the control state (such as light switch state, dimming parameter), scene mode configuration, time table plan and other core data are stored in different protocol control nodes, and there is a lack of unified data interaction and synchronization mechanism. When the protocol switches or the network fluctuates, problems such as "instruction execution asynchronization" and "state display inconsistency" may occur, for example, BMS displays light off but local KNX panel displays on, leading to control logic conflict.

[0005] 3. Insufficient system fault tolerance and degradation capability: When the main communication network (such as the IP network relied on by BACnet) is interrupted, the existing system mostly loses core control capability, and can only realize basic lighting through simple manual switching, and cannot maintain hierarchical control using the redundancy capability of the field layer bus (such as KNX TP bus). Especially in the emergency lighting scene of high-end buildings, this defect may cause safety hazards.

[0006] 4. High complexity and high cost of operation and maintenance: Multi-protocol configuration requires the use of special tools, and different protocols require professional technicians to operate separately, resulting in long system integration period, high debugging difficulty, and high post-operation and maintenance cost. At the same time, when the protocol is upgraded or a new protocol is added, the system needs to be reconstructed on a large scale, and the scalability is poor.

[0007] Therefore, there is an urgent need for an intelligent lighting control system that can realize intelligent adaptation, seamless switching, state consistency and high reliability fault tolerance of management layer and field layer multi-protocol, to meet the stringent requirements of high-end intelligent buildings. SUMMARY

[0008] The present application belongs to the technical field of intelligent building equipment management system (BMS) and lighting control fusion, and particularly relates to an intelligent lighting control system and a corresponding control method for realizing intelligent collaborative switching of multiple industrial control protocols, cross-protocol control state consistency guarantee and network fault self-fault-tolerance in a multi-level network architecture of building automation. The present application solves the problem of heterogeneous fusion of centralized control protocols in the management layer and distributed control protocols in the field layer in high-end intelligent buildings, and can be widely applied to commercial complexes, Class A office buildings, smart parks and other scenes with strict requirements on lighting control reliability and compatibility.

[0009] In view of the technical problems of protocol heterogeneous collaboration difficulty, cross-protocol state synchronization not in real time, insufficient system fault tolerance and complex operation and maintenance in the prior art, the core purpose of the present application is to provide an intelligent lighting control system based on multi-protocol dynamic switching and a control method thereof.

[0010] The specific purposes include: Realize gateway-free intelligent switching of multi-protocol between the management layer and the field layer, and eliminate the obstacle of heterogeneous protocol fusion; Establish a unified state storage and synchronization mechanism to guarantee the real-time consistency of cross-protocol control state; Build a multi-level fault tolerance degradation system to ensure the continuity and reliability of lighting control in network anomalies; Simplify the multi-protocol configuration and operation and maintenance process, and reduce the system integration and post-maintenance cost; Improve the scalability of the system to support flexible expansion and technical upgrade of future protocol types.

[0011] Specifically, the following technical solutions are included: An intelligent lighting control system based on multi-protocol dynamic switching, comprising a lighting controller, a multi-protocol communication module, a protocol arbitration module, a unified state storage, a local logic execution engine and a human-computer interaction interface, each module realizes data interaction through an internal high-speed bus.

[0012] Preferably, the lighting control device comprises 8-16 independent control loops, each supporting 16A / 20A high current load output, and is configured with a manual emergency switch, a dry contact input interface, and an overload, short circuit, and over-temperature protection circuit, and can verify the load on / off state through a loop current detection module; The multi-protocol communication module adopts a modular hardware design, integrates at least two independent protocol transceiving units, supports parallel operation of management layer protocols and field layer protocols, and is independent in physical layer. The protocol arbitration module comprises a communication quality monitoring subunit, a health degree evaluation subunit, and a switching decision subunit; the communication quality monitoring subunit adopts a "polling + interruption combined" monitoring timing, and collects multi-dimensional operation parameters of each protocol channel in real time; the health degree evaluation subunit calculates the health degree score of each protocol based on a preset weight algorithm; and the switching decision subunit can perform an atomized protocol switching operation, can send a hardware level interruption signal interception instruction, and can control the control right handover. The unified state memory adopts a redundant design of NOR Flash and an SD card, constructs a unified state data model, centrally stores real-time states of control loops, scene configuration parameters, time table plans, protocol mapping relationship tables, and fault logs, divides a main storage area, a backup area, a local change log partition, and a monitoring log partition, supports real-time writing, snapshot backup, and cyclic coverage storage of control states, and provides a standardized data interface to ensure atomicity and consistency of data reading and writing. The local logic execution engine is built-in with a high-precision real-time clock, supports year / month / day / hour / minute level time table programming, and integrates logical function blocks such as AND / OR / NOT, delay, and threshold comparison; has illumination and human body sensor input interfaces, can take over the control right to perform autonomous control when a network anomaly occurs; supports fire linkage signal access, and preferentially executes emergency lighting control logic and shields non-emergency instructions in an emergency scenario. The human-computer interaction interface comprises a local LCD display panel, a key group, and a remote communication interface; the local panel can visually display protocol running states, loop states, and fault information, and the key group supports protocol parameter configuration and manual control; the remote communication interface supports HTTP / JSON protocols, and realizes remote configuration of multi-protocol parameters, state monitoring, and fault log reading.

[0013] Preferably, the management layer protocol supported by the multi-protocol communication module is BACnet / IP, and the field layer protocol is KNX TP1; the protocol transceiving unit is modularly designed, and corresponding protocol modules can be replaced according to requirements; the BACnet / IP unit supports a TCP / IP protocol stack and a BACnet BBMD broadcast service, and the KNX TP1 unit adopts an NCN5120 transceiving chip, supports bus voltage detection, and supports a multicast mechanism.

[0014] Preferably, the health degree evaluation subunit of the protocol arbitration module adopts a weighted algorithm to calculate the health degree score, and the score formula is: V Health =Σ( w i × f i ( x i ))× 100 ; For Ethernet protocol monitoring, the response delay, bit error rate, link persistence, signal strength, and retransmission number are monitored; for bus field layer protocol, the bus voltage, telegraph error rate, group address communication success rate, and bus load rate are additionally included; The index parameter weight and normalization function of the Ethernet protocol are as follows: Indicator Weight Normalization function (x) Parameter description Response delay D 0.30 f (D) = 0.5 e (-D / τ) ]]> ​ = 500 ms (time constant) Error rate BER 0.25 <![CDATA[ f (BER)= max(0, 1-10× log 10 (BER+10 -6 ))]]> Logarithmic compression Link persistence C 0.20 f (C) = C α ]]> ​ = 0.7 (reward high persistence) Signal strength R 0.15 <![CDATA[ f (R) = ( R - R min ) / ( R max - R min )]]> <![CDATA[ R min =-90dBm, R max =-30dBm]]> Number of retransmissions N 0.10 f (N) = max(0, 1- N / T n )]]> ​ T n = 5th order ​ The index parameter weight and normalization function of the bus field layer protocol are as follows: Indicator Weight Normalization function (x) Parameter description Bus voltage V 0.25 (V) = piecewise function Standard voltage 24 V ± 10% Telegraph error rate E 0.20 f (E) = max(0, 1 - E / T e )]]> ​ T e = 0.005 ​ Group address success rate S 0.18 (S) = S ∈[0,1] Bus load rate L 0.12 f (L) = max(0, 1 - ( L / T l ) 2 )]]> ​ T l = 0.4]]> ​ Response delay D 0.10 f (D) = 0.5 e (-D / τ) ]]> ​ = 200 ms (time constant) Link persistence C 0.06 f (C) = C α ]]> ​ = 0.7 (reward high persistence) Signal strength R 0.05 f (R) = ( R - R min ) / ( R max - R min )]]> ​ <![CDATA[ R min =-90dBm, R max =-30dBm]]> Number of retransmissions N 0.04 <![CDATA[ f (N) = max(0, 1- N / T n )]]> T n =5th ​ According to the score results, the system state is divided, and the switching decision table is as follows: Scoring interval Status Switching strategy Explanation 80-100 Healthy Keep current protocol All indicators are normal, system is stable 60-79 Warning Monitor backup protocol Some indicators have decreased, prepare to switch 40-59 Abnormal Trigger switching process Master protocol < 60 min for 300 ms 20-39 Serious Immediately forced switching Main protocol serious failure 0-19 Failure Degraded local control All protocol channels are unavailable .

[0015] Preferably, the protocol mapping relationship table of the unified state memory is pre-configured with the corresponding relationship between different protocol objects; the difference synchronization and state calibration based on the time stamp are supported; The sensor input interface of the local logic execution engine supports 0~10 V analog signal and dry contact signal access; the emergency control logic includes forcibly opening all emergency lighting loops during fire linkage, and executing the time table and sensor linkage logic in a non-emergency scene; The LCD panel of the human-computer interaction interface can display initialization results, protocol exception information, and the current control mode; the fault log can record hardware fault codes, protocol fault codes, switching time stamps, and information such as the reason for triggering degradation, and supports remote reading and local inquiry.

[0016] An intelligent lighting control method based on multi-protocol dynamic switching, applying the system as claimed in any one of the preceding embodiments, characterized in that it comprises the following steps: Step S1: system initialization, executing a hierarchical verifiable process; Step S2: protocol communication quality monitoring; Step S3: protocol health degree evaluation and switching triggering; Step S4: seamless switching and state synchronization; Step S5: instruction receiving and state broadcasting; Step S6: Fault-tolerant degradation and state rollback.

[0017] Preferably, the step S1 specifically comprises: ① core module connection state detection by GPIO pin scanning, abnormality red LED alarm and record fault code; ② reading unified state memory preset configuration parameters, parameters using "main parameters+CRC-16 check code" format, check failure then load default configuration; ③ initialization of multi-protocol stack, network connection with upper management system and field device, initialization failure then mark channel exception and preferentially enable standby protocol stack; ④ control loop on-off self-test, loop fault state detection and manual emergency switch initial state, initial state data written into main memory area and backup area; ⑤ update system running state to "initialization complete" and record initialization time consumption; The step S2 specifically comprises: protocol arbitration module collects multi-dimensional indicators of each protocol channel according to "polling+interruption combination" timing, signal strength, response delay, error rate, link persistence and retransmission times for Ethernet protocol; bus voltage, telegraph error rate, group address communication success rate and bus load rate for bus protocol; collected data is written into monitoring log partition after abnormal value filtering and standardization processing, and feedback through LCD panel and state indicator light in abnormality; The step S3 specifically comprises: health degree evaluation subunit calculates protocol health degree score based on preset weight algorithm; when main protocol health degree is lower than preset threshold for 3 consecutive monitoring periods, and standby protocol health degree is higher than threshold, trigger protocol switching process; when main protocol health degree restores to above threshold and lasts for 3 periods, trigger back switching process; The step S4 specifically comprises: switching decision subunit executes the following operations: ① send hardware level interruption signal to lock each protocol receiving buffer, inform external "switching" state; ② read control loop core state data through DMA channel, generate standardized state snapshot, store to independent backup partition after CRC-32 check; ③ execute atomic protocol stack switching, close main protocol physical layer module and release resources, initialize standby protocol parameters and load configuration file; ④ complete state data cross-protocol conversion and batch synchronization based on protocol mapping relationship table, verify data consistency after synchronization; ⑤ update protocol running state identifier, unlock buffer and clear "switching" flag; whole process time consumption≤100 ms; The step S5 specifically comprises: ① unlocking the protocol receiving buffer, opening the instruction receiving permission by priority using the "gradient receiving" mechanism, updating the system running state and recording the switching log; ② verifying the actual state through the current detection module after receiving and executing the control instruction, and writing the same into the unified state memory according to the standardized format, or triggering the retry mechanism if the states are inconsistent; ③ performing differentiated broadcasting based on the activated protocol to ensure that the device states in the same network are consistent; and ④ synchronizing the key state data to the standby protocol buffer area in increments and establishing an index table, and sending a "cache ready" notification; The step S6 specifically comprises: ① triggering fault-tolerant degradation when the health degree of all protocol channels is below the threshold value (default 50 points) for 3 consecutive monitoring periods, sending a hardware-level control right transfer signal to the local logic execution engine, setting the control mode to "local emergency mode", and closing the protocol transceiver unit physical layer module; ② the local logic execution engine loads the emergency control strategy, executes the time table and sensor linkage logic, records all state changes to the local change log and prompts through the LCD and LED; ③ after any protocol channel is restored to normal, the local change log is extracted to generate a change list, which is synchronized to the corresponding system / device using the differential synchronization mechanism, and after the state consistency is calibrated, the control right is returned to the protocol control unit, and the local emergency prompt is closed.

[0018] Preferably, the configuration parameters of the step S1 include protocol type configuration, master protocol priority weight, health degree evaluation weight coefficient, switching threshold, and basic parameters of each protocol unit; the initialization time consumption is less than or equal to 3 seconds by default; and the step S2 uses the 3σ criterion for abnormal value filtering, and the data standardization uniformly quantizes the indicators to 0-100 points.

[0019] Preferably, in the step S2, the response delay of the BACnet / IP protocol is the average value of the response time of 3 consecutive read requests, the default threshold is less than or equal to 200 ms, the error code rate threshold is less than or equal to 1%, and the retransmission number threshold is less than or equal to 3 times per period; the bus voltage standard range of the KNX TP1 protocol is 24V±10%, the telegraph error rate threshold is less than or equal to 2%, the group address communication success rate is greater than or equal to 95%, and the bus load rate threshold is less than or equal to 30%; the hardware interrupt is triggered immediately when the bus voltage is abnormal.

[0020] Preferably, the state snapshot of the step S4 is 16 bytes per loop, including loop switch state, dimming parameter, running scene ID, and fault alarm state; batch synchronization is processed according to 8 loops per batch; the broadcast period of the step S5 is 100 ms, the KNX state telegraph conforms to the ETS standard and the priority is set to "high", and the success rate of sending is greater than or equal to 99.5%; the capacity of the standby protocol buffer area is greater than or equal to 1MB and supports power-off caching; And / or, the step S6 degradation trigger judgment period is 300 ms by default, the state change log of local control is recorded in the format of "loop ID-operation type-target state-time stamp-trigger source"; the synchronization response timeout time of state rollback is 500 ms, the timeout retry is 2 times, and the synchronization success rate is greater than or equal to 99.8%; the state calibration is based on the local change log.

[0021] Compared with the prior art, the present application has the following remarkable beneficial effects: Seamless integration of heterogeneous protocols: through the parallel operation of multiple protocols and intelligent arbitration design, the dynamic switching of management layer and field layer protocols without gateway is realized, eliminating the delay and failure risk caused by traditional gateway conversion, adapting to the multi-level control needs of high-end intelligent buildings; supporting the deep integration of mainstream protocols such as BACnet and KNX, with compatibility covering more than 80% of building automation protocol types.

[0022] Strictly consistent control state: through unified state memory and real-time synchronization mechanism, centralized management and bidirectional synchronization of cross-protocol control data are realized, completely solving the problem of inconsistent state display and control logic conflict in the prior art; state synchronization time ≤100 ms, ensuring that users have no perception during switching process.

[0023] Multi-level fault-tolerant high-reliability operation: a three-level fault-tolerant system of "main protocol-backup protocol-local control" is constructed, which automatically runs in degraded mode when the network is abnormal, preferentially uses the high-reliability field layer bus to maintain control, and ensures control continuity in emergency scenarios to meet the requirements of GB 50034-2024 "Building Lighting Design Standard"; the local control mode supports fire linkage to improve building safety level.

[0024] Significant reduction in operation and maintenance cost: through unified human-computer interaction interface and remote configuration function, centralized configuration and state monitoring of multi-protocol parameters are realized without relying on multiple special debugging tools; supporting automatic recording of fault log and remote diagnosis, reducing the amount of field maintenance, and reducing operation and maintenance cost by more than 30% through actual measurement.

[0025] Strong expansion capability and good compatibility: modular hardware design and layered software architecture are adopted, and when adding a new protocol type, only the corresponding communication module needs to be replaced and the protocol stack software needs to be upgraded, without the need to restructure the system; supporting seamless connection with existing building automation systems, it can be widely applied to new projects and renovation projects, and is suitable for multiple fields such as commercial, office and industrial. BRIEF DESCRIPTION OF DRAWINGS

[0026] The present application will be further described in detail below with reference to the accompanying drawings: Fig. 1 : The schematic diagram of the architecture of the system of the present application; Fig. 2 : Protocol health assessment and arbitration flowchart; Fig. 3 State synchronization and protocol switching timing diagram. DETAILED DESCRIPTION

[0027] The design scheme is: An intelligent lighting control system based on multi-protocol dynamic switching, comprising a lighting controller, a multi-protocol communication module, a protocol arbitration module, a unified state memory, a local logic execution engine and a man-machine interaction interface, each module realizes data interaction through an internal high-speed bus; wherein: The lighting controller has 8-16 independent control loops, each loop supports 16 A / 20 A high current load output, is configured with a manual emergency switch, a dry contact input interface and an overload, short circuit and over temperature protection circuit, and can verify the load on-off state through a loop current detection module; The multi-protocol communication module adopts a modular hardware design, integrates at least two independent protocol transceiving units, respectively supports the parallel operation of management layer protocol and field layer protocol, and the physical layers of each protocol unit are independent of each other; each protocol transceiving unit is configured with an independent monitoring buffer area and supports receiving buffer locking / unlocking control; The protocol arbitration module includes a communication quality monitoring subunit, a health degree evaluation subunit and a switching decision subunit; the communication quality monitoring subunit adopts a "polling + interruption combined" monitoring timing, and collects multi-dimensional running parameters of each protocol channel in real time; the health degree evaluation subunit calculates the health degree score of each protocol based on a preset weight algorithm; the switching decision subunit can execute an atomized protocol switching operation, can send a hardware level interruption signal interception instruction and control the control right handover; The unified state memory adopts a redundant design of NOR Flash and SD card, builds a unified state data model, centrally stores control loop real-time state, scene configuration parameters, time table plan, protocol mapping relationship table and fault log, divides main storage area, backup area, local change log partition and monitoring log partition, supports real-time writing, snapshot backup and cyclic coverage storage of control state, provides a standardized data interface to ensure atomicity and consistency of data reading and writing; The local logic execution engine is built-in with a high-precision real-time clock (RTC), supports year / month / day / hour / minute level time table programming, integrates logical function blocks such as AND / OR / NOT, delay, threshold comparison, etc.; has illumination and human body sensor input interfaces, can take over the control right to execute autonomous control when network abnormity occurs; supports fire linkage signal access, and executes emergency lighting control logic preferentially and shields non-emergency instructions in an emergency scene; The human-computer interaction interface includes a local LCD display panel, a key group and a remote communication interface; the local panel can visually display protocol running state, loop state and fault information, the key group supports protocol parameter configuration and manual control; the remote communication interface supports HTTP / JSON protocol, realizes multi-protocol parameter remote configuration, state monitoring and fault log reading.

[0028] The management layer protocol supported by the multi-protocol communication module is BACnet / IP, and the field layer protocol is KNX TP1; the protocol transceiver unit is modularly designed, and the corresponding protocol module can be replaced according to requirements; wherein the BACnet / IP unit supports TCP / IP protocol stack and BACnet BBMD broadcast service, and the KNX TP1 unit adopts NCN5120 transceiver chip, supports bus voltage detection and multicast mechanism.

[0029] The health degree evaluation sub-unit of the protocol arbitration module adopts a weighted algorithm to calculate the health degree score, and the score formula is: V Health =Σ( w i × f i ( x i ))× 100。

[0030] For Ethernet protocol monitoring, the response delay, error rate, link persistence, signal strength and retransmission times are monitored; for bus type field layer protocol, the bus voltage, telegraph error rate, group address communication success rate and bus load rate are additionally monitored; the monitoring period can be self-defined, and the default is 100 ms / time.

[0031] The Ethernet protocol index parameter weight and normalization function are shown in Table 1: Table 1 Indicator Weight Normalization function (x) Parameter description Response delay D 0.30 f (D) = 0.5 e (-D / τ) ]]> ​ = 500 ms (time constant) Error rate BER 0.25 <![CDATA[ f (BER) = max(0, 1-10x log 10 (BER+10 -6 ))]]> Logarithmic compression Link persistence C 0.20 f (C) = C α ]]> ​ = 0.7 (reward high persistence) Signal strength R 0.15 f (R) = ( R - R min ) / ( R max - R min )]]> ​ <![CDATA[ R min =-90 dBm, R max =-30 dBm]]> Number of retransmissions N 0.10 f (N) = max(0, 1- N / T n )]]> ​ T n =5th]]> ​ The bus type field layer protocol index parameter weight and normalization function are shown in Table 2: Table 2 Indicator Weight Normalization function (x) Parameter description Bus voltage V 0.25 (V) = piecewise function Standard voltage 24 V ± 10% Telegraph error rate E 0.20 f (E) = max(0, 1 - E / T e )]]> ​ T e = 0.005]]> ​ Group address success rate S 0.18 (S) = S ∈[0,1] Bus load rate L 0.12 f (L) = max(0, 1 - ( L / T l ) 2 )]]> ​ T l = 0.4 ​ Response delay D 0.10 f (D) = 0.5 e (-D / τ) ]]> ​ = 200 ms (time constant) Link persistence C 0.06 f (C) = C α ]]> ​ = 0.7 (reward high persistence) Signal strength R 0.05 <![CDATA[ f (R) = ( R - R min ) / ( R max - R min )]]> <![CDATA[ R min =-90 dBm, R max =-30 dBm]]> Number of retransmissions N 0.04 f (N) = max(0, 1- N / T n )]]> ​ T n =5th ​ According to the score results, the system state is divided, and the switching decision table is shown in Table 3: Table 3 Scoring interval Status Switching strategy Explanation 80-100 Healthy Keep current protocol All indicators are normal, system is stable 60-79 Warning Monitor backup protocol Some indicators have decreased, prepare to switch 40-59 Abnormal Trigger switching process Master protocol < 60 min for 300 ms 20-39 Serious Immediately forced switching Main protocol serious failure 0-19 Failure Degraded local control All protocol channels are unavailable The protocol mapping relationship table of the unified state memory preconfigures the corresponding relationship between different protocol objects (including the mapping of BACnet object ID and KNX group address, Modbus register address); supports timestamp-based difference synchronization and state calibration, and the local change log partition retains the latest 1000 change records, and the key emergency operation record is marked as “permanent retention”.

[0032] The sensor input interface of the local logic execution engine supports 0-10V analog signal (light sensor) and dry contact signal (human body sensor) access; the emergency control logic includes forcibly turning on all emergency lighting loops (dimming value 100%) during fire linkage, and executing schedule and sensor linkage logic in non-emergency scenarios.

[0033] The LCD panel of the human-computer interaction interface can display initialization results, protocol exception information, and current control mode; fault logs can record hardware fault codes, protocol fault codes, switching timestamps, and downgrade trigger reasons, and support remote reading and local inquiry.

[0034] An intelligent lighting control method based on multi-protocol dynamic switching, comprising the following steps: Step S1: system initialization, performing a hierarchical verifiable process, including: ① hardware minimum system self-checking, detecting the connection state of the core module through GPIO pin scanning, and if abnormal, the red LED flashes to alarm and record the fault code; ② reading the preset configuration parameters of the unified state memory, the parameters are in the format of "main parameters+CRC-16 check code", and if the verification fails, the default configuration is loaded; ③ initializing the multi-protocol stack, establishing network connection with the upper management system and field devices, and if the initialization fails, marking the channel exception and preferentially enabling the standby protocol stack; ④ control loop on-off self-checking, detecting the loop fault state and the initial state of the manual emergency switch, and writing the initial state data into the main storage area and the backup area; ⑤ updating the system running state to "initialization completed" and recording the initialization time consumption; Step S2: protocol communication quality monitoring, the protocol arbitration module collects multi-dimensional indicators of each protocol channel according to the "polling+interruption combination" timing, collects signal strength, response delay, error rate, link persistence, and retransmission times for Ethernet type protocols; additionally collects bus voltage, telegraph error rate, group address communication success rate, and bus load rate for bus type protocols; after the collected data is filtered for abnormal values and standardized, it is written into the monitoring log partition, and when abnormal, it is fed back through the LCD panel and the state indicator light; Step S3: protocol health evaluation and switching trigger, the health evaluation subunit calculates the health score (full score 100) of each protocol based on a preset weight algorithm; when the health score of the main protocol is lower than the preset threshold (default 60) for 3 consecutive monitoring periods, and the health score of the standby protocol is higher than the threshold, the protocol switching process is triggered; when the health score of the main protocol recovers to above the threshold and lasts for 3 periods, the back switching process is triggered; Step S4: seamless switching and state synchronization, the switching decision subunit performs the following operations: ① send a hardware level interrupt signal to lock each protocol receiving buffer, and inform the outside that the state is "switching"; ② read the control loop core state data through the DMA channel, generate a standardized state snapshot, and store it in the independent backup partition after CRC-32 verification; ③ perform atomic protocol stack switching, close the main protocol physical layer module and release the resources, initialize the standby protocol parameters and load the configuration file; ④ complete the state data cross-protocol conversion and batch synchronization based on the protocol mapping relationship table, and verify the data consistency after synchronization; ⑤ update the protocol running state identifier, unlock the buffer and clear the "switching" flag; the entire process takes ≤100 ms; Step S5: instruction reception and state broadcast, including: ① unlock the protocol receiving buffer, open the instruction reception permission by priority using the "gradient reception" mechanism, update the system running state and record the switching log; ② after receiving the control instruction and executing it, verify the actual state through the current detection module, and if they are consistent, write them into the unified state storage in a standardized format (first write to the backup area and then to the main storage area), and if they are inconsistent, trigger the retry mechanism; ③ perform differentiated broadcast based on the activated protocol to ensure that the device states within the same network are consistent; ④ synchronize the key state data to the standby protocol buffer area in increments and establish an index table, and send a "cache ready" notification; Step S6: fault tolerance degradation and state rollback, including: ① when the health degree of all protocol channels is below the threshold (default 50 points) for 3 consecutive monitoring periods, trigger fault tolerance degradation, send a hardware level control right transfer signal to the local logic execution engine, set the control mode to "local emergency mode", and close the protocol transceiver unit physical layer module; ② the local logic execution engine loads the emergency control strategy, executes the time table and sensor linkage logic, and records all state changes to the local change log and prompts through the LCD and LED; ③ after monitoring that any protocol channel has recovered to normal, extract the local change log to generate a change list, synchronize it to the corresponding system / device using the differential synchronization mechanism, complete the state consistency calibration, and return the control right to the protocol control unit, and close the local emergency prompt; Preferably, the configuration parameters of step S1 include protocol type configuration, main protocol priority weight (1-5 levels), health degree evaluation weight coefficient, switching threshold, and basic parameters of each protocol unit; the initialization time is ≤3 seconds by default; the step S2 uses the 3σ criterion for outlier filtering, and the data standardization uniformly quantizes the indicators to 0-100 points.

[0035] Preferably, in the step S2, the response delay of the BACnet / IP protocol is the average of the response time of 3 consecutive read requests, the default threshold is ≤200 ms, the error code rate threshold is ≤1%, and the retransmission number threshold is ≤3 times per cycle; the bus voltage standard range of the KNX TP1 protocol is 24V±10%, the telegraph error rate threshold is ≤2%, the group address communication success rate is ≥95%, and the bus load rate threshold is ≤30%; a hardware interrupt is triggered immediately when the bus voltage is abnormal.

[0036] Preferably, the state snapshot of the step S4 is 16 bytes per loop, including the loop switch state, the dimming parameter, the running scene ID, and the fault alarm state; the batch synchronization is processed according to 8 loops per batch; the broadcast cycle of the step S5 is 100 ms, the KNX state telegraph conforms to the ETS standard and the priority is set to “high”, and the sending success rate is ≥99.5%; the backup protocol buffer capacity is ≥1MB and supports power-off caching.

[0037] Preferably, the degradation trigger judgment cycle of the step S6 is 300 ms by default, the state change log of the local control is recorded in the format of “loop ID-operation type-target state-time stamp-trigger source”; the synchronization response timeout time of the state rollback is 500 ms, the timeout retry is 2 times, and the synchronization success rate is ≥99.8%; the state calibration is based on the local change log.

[0038] The specific technical architecture is as shown in Fig. 1~Fig. 3 .

[0039] The application provides an intelligent lighting control method based on multi-protocol dynamic switching, which realizes reliable lighting control in a multi-protocol environment through four core links of protocol state real-time monitoring, health degree dynamic evaluation, seamless switching and state synchronization, and fault-tolerant degradation, and specifically includes the following steps: Step S1: system initialization. After the system is powered on, a hierarchical and verifiable initialization process is performed to ensure that the parameter configuration of each module is accurate and the network connection is reliable, and the specific implementation is as follows: ① Power-on self-test. The system first performs a hardware minimum system self-test to detect the hardware connection state of core modules such as the lighting controller, the multi-protocol communication module, and the unified state memory through GPIO pin scanning. If the module is detected to be unresponsive (such as the unified state memory not responding), the red LED indicator light of the human-computer interaction interface will flash to alarm (flash frequency 2 times / s), and the hardware fault code will be recorded to the temporary storage area; if the hardware self-test is passed, the green LED indicator light is always on, and the parameter loading stage is entered.

[0040] ② Configuration parameter loading. Read the preset configuration parameter area data in the unified state storage through the SPI interface. The configuration parameters adopt the storage format of "main parameter + check code". The core parameters include: protocol type configuration (the main protocol is BACnet / IP, and the standby protocol is KNX TP1), main protocol priority weight (range 1-5 levels, with level 5 being the highest), health degree evaluation weight coefficient (the sum is 1), switching threshold (default 60 minutes), and basic parameters of each protocol unit (such as the IP address, subnet mask, and gateway of BACnet / IP, and the physical address and baud rate 9600 bps of KNX TP1). After loading, the parameter integrity is verified through the CRC-16 check algorithm. If the verification fails, the default configuration parameters are loaded, and "configuration parameter exception" is marked to the fault log. w i

[0041] ③ Multi-protocol stack initialization. Based on the loaded protocol configuration parameters, the protocol stacks of each protocol transceiver unit are initialized in turn: For the BACnet / IP protocol unit: initialize the TCP / IP protocol stack, configure the BACnet device object (device ID, object name), register the standard BACnet objects such as analog input and binary output, complete address resolution with the gateway through the ARP protocol, establish a TCP connection with the BMS system and complete device registration.

[0042] For the KNX TP1 protocol unit: initialize the physical layer transceiver, configure the KNX physical address and group address binding relationship, start the KNX bus listening mode, and complete the bus handshake with the field KNX device.

[0043] During the initialization process, if a protocol stack initialization fails (such as BACnet cannot connect to BMS), mark the protocol channel as "initialization failed", and preferentially enable the standby protocol stack initialization.

[0044] ④ Control loop self-check and initial state storage. The lighting controller performs on-off self-check on each independent control loop. By closing / opening the drive relay, the loop current feedback signal (current should be ≤50 mA when there is no load) is detected to determine whether there is a short circuit or open circuit fault. At the same time, the initial state of the manual emergency switch is read (default open is 0, and closed is 1). After the self-check is completed, the "fault state (normal / short circuit / open circuit)" "initial switch state" "default dimming value" of each loop are written into the main storage area and backup area of the unified state storage in a standardized format (loop ID + state identifier + value + timestamp), ensuring the redundancy and reliability of the initial state data.

[0045] ​⑤ Initialization is completed. Update the "system running status" field in the unified state memory to "initialization completed", record the initialization time (default < 3 seconds) and the status of each module to the fault log; display the initialization result through the LCD panel of the human-computer interaction interface, and complete the entire initialization process.

[0046] Step S2: protocol communication quality monitoring. The protocol arbitration module performs periodic and multi-dimensional communication quality collection on each protocol channel through a time division multiplexing monitoring mechanism, ensuring the real-time and accuracy of the monitoring data, and the specific implementation is as follows: ① Monitoring timing plan. The monitoring timing plan adopts "polling + interruption combination", and the monitoring period can be customized by configuration parameters (default 100 ms / time). Each monitoring period polls each protocol channel in the order of protocol priority (main protocol priority). At the same time, a hardware interruption triggering mechanism is configured for key monitoring indicators (such as bus voltage, link interruption) to ensure that abnormal states can be captured in time. During the monitoring process, the system allocates an independent monitoring buffer area for each protocol channel to avoid data confusion.

[0047] ② Ethernet protocol (BACnet / IP) monitoring. Through the state register and statistical module of the TCP / IP protocol stack, the following core indicators are collected: Signal strength: obtained through the signal detection pin of the Ethernet PHY chip, quantified as 0-100 points (≥ 80 points indicates good signal, < 50 points indicates weak signal).

[0048] Response delay: records the time difference between sending a BACnet read request message and receiving a response message, in ms, and takes the average of 3 consecutive collections (default threshold < 200 ms).

[0049] Error rate: statistics the ratio of the number of CRC check failures to the total number of received messages in the current monitoring period (error rate = check failure number / total message number x 100%, default threshold < 1%).

[0050] Link persistence: determine whether the link is persistent by the TCP connection state identifier (connection state "ESTABLISHED" indicates persistence, otherwise interruption).

[0051] Number of retransmissions: read the retransmission counter of the TCP protocol stack to count the number of message retransmissions in the current period (default threshold < 3 times / period).

[0052] After all indicators are collected, write them into the monitoring buffer area in the format of "protocol type + monitoring timestamp + indicator value".

[0053] ③ Bus protocol (KNX TP1) monitoring. In addition to collecting the above response delay, link persistence, signal strength, and retransmission number indicators, the following exclusive indicators are collected through the KNX transceiver chip and bus detection circuit: Bus voltage: Collect the differential voltage of KNX TP1 bus through ADC module, the standard range is 24 V ± 10% (i.e. 21.6 V - 26.4 V), and out of range is marked as voltage abnormality.

[0054] Telegraph error rate: Count the number of check errors, length errors, and address errors of KNX telegrams in the current period, and the ratio to the total number of received telegrams (default threshold ≤ 2%).

[0055] Group address communication success rate: Send a test telegram to the preset KNX group address (send 1 time per period), and count the ratio of the number of received response telegrams to the number of sent telegrams (success rate ≥ 95% is normal).

[0056] Bus load rate: Count the ratio of the time the bus is occupied to the monitoring period in the current period (default threshold ≤ 30%, high load rate will cause communication congestion).

[0057] During the collection process, if the bus voltage is detected to be lower than 21.6 V or higher than 26.4 V, a hardware interrupt is triggered immediately, and the protocol channel is marked as "emergency exception".

[0058] ④ Monitoring data preprocessing. The raw monitoring data collected by each protocol channel is preprocessed, including: Outlier filtering: 3 σ criteria are used to remove obviously abnormal raw data, and the valid value of the previous period is used to replace it.

[0059] Data standardization: Quantify different dimension indicators into standard scores of 0-100 points.

[0060] Data backup: The preprocessed monitoring data is written into the monitoring log partition of the unified state memory simultaneously, retaining the last 1000 monitoring periods of data for subsequent health assessment and fault tracing.

[0061] ⑤ Monitoring state feedback. If the key indicators of a protocol channel appear abnormal, the LCD panel of the human-computer interaction interface displays the abnormal information immediately, and the state indicator light of the corresponding protocol unit flashes; if all protocol channels are normal, the state indicator light remains constant, completing the current monitoring period.

[0062] Step 3: Protocol health assessment and switching trigger. The health assessment sub-unit calculates the health score of each protocol based on the preset weight algorithm (full score is 100 points). The scoring formula is: VHealth =∑(i=1 w i × f i ( x i ))× 100 The BACnet / IP protocol index parameter weight and normalization function is shown in Table 1.

[0063] The KNX TP1 protocol index parameter weight and normalization function is shown in Table 2.

[0064] According to the scoring results, the system state is divided, and the switching decision table is shown in Table 3.

[0065] When the primary protocol health score is continuously lower than the preset threshold (default 60 points) for 3 monitoring periods, and the standby protocol health score is higher than the threshold, the protocol switching process is triggered; if the primary protocol health score recovers to above the threshold and lasts for 3 periods, the protocol switching process is triggered. The specific protocol health assessment and arbitration process is shown in Fig. 2 .

[0066] Step S4: seamless switching and state synchronization. The switching decision subunit executes a refined seamless switching process, which is implemented as follows: ①Switching trigger and preparation. Send a hardware-level interrupt signal to each protocol transceiver unit, trigger instruction reception buffer locking, and refuse to write new control instructions (only reading permission is retained), and at the same time, inform the upper management system and the field device of the "switching" state through the state flag bit, to avoid conflicts caused by repeated external instruction sending. Through the DMA (Direct Memory Access) channel, all control loop core state data in the unified state memory is read at high speed, including loop switch state (binary value), dimming parameter (0-100% quantization value), current running scene ID, fault alarm state, etc., to generate a 16-byte / loop standardized state snapshot; after the snapshot data is integrity checked by the CRC-32 checking algorithm, it is stored in the independent backup partition of the unified state memory (the backup partition uses a write protection mechanism to prevent data tampering during the switching process).

[0067] ②Protocol stack switching. Perform atomic switching operation through the protocol stack management interface, first close the physical layer transceiver of the primary protocol stack, release the system resources occupied by the protocol (including CPU interrupt, memory buffer), then initialize the physical layer and data link layer parameters of the standby protocol stack, and load the preset protocol configuration file (including group address mapping table, communication timeout threshold).

[0068] ③ Cross-protocol state synchronization. Based on the protocol mapping table in the unified state storage (pre-configured correspondence between BACnet object IDs and KNX group addresses), the data in the state snapshot is converted into the data format of the target protocol - BACnet binary output object values are converted into KNX standard telegrams, and the converted data is written to the corresponding protocol object through the application layer interface of the standby protocol stack. The synchronization process uses a batch transmission mode, processing 8 loop state data per batch, and the data consistency is confirmed by checking the checksum after synchronization is completed.

[0069] ④ Switching end. Update the protocol running state identifier in the unified state storage, update "primary protocol: BACnet" to "primary protocol: KNX", unlock the instruction receiving buffer of each protocol channel, and clear the "switching" state flag bit. The entire switching process is optimized through hardware acceleration and parallel processing, with a total time consumption controlled within 100 ms (protocol stack switching time ≤ 30 ms, state synchronization time ≤ 50 ms, and the remaining time ≤ 20 ms), ensuring that the lighting output does not flicker or lag, and realizing user- unaware switching.

[0070] Step S5: Instruction reception and state broadcast. After switching is completed, the system performs a fine instruction recovery and state synchronization broadcast process to ensure the stability and state consistency of the control link after protocol switching. The specific implementation is as follows: ① Instruction reception recovery. The switching decision subunit sends an unlock instruction to each protocol transceiver unit, removes the write restriction of the instruction receiving buffer, and clears the "switching" state flag bit. To avoid instruction congestion at the moment of unlocking, a "gradient reception" mechanism is adopted, which first opens the reception permission of low-priority instructions (such as state query instructions), and delays for 50 ms before opening the reception permission of high-priority instructions (such as switch and dimming control instructions). Simultaneously, update the "protocol running state" field in the unified state storage to "normal operation", and record the switching completion timestamp and target protocol type to the fault log.

[0071] ② Real-time state change writing and verification. After receiving control instructions through the activated protocol channel, the lighting controller performs corresponding operations, and immediately collects the actual running state of each loop after the operation is completed. If consistent, write the state data in a standardized format (including loop ID, state type, value, and timestamp) to the unified state storage in real time. The writing process adopts a dual-zone writing mechanism of "writing to backup area first, then to main storage area", ensuring data storage reliability. If the state is inconsistent, mark it as "execution exception" and trigger the retry mechanism, with a maximum of 3 retries, a retry interval of 10 ms, and recording of abnormal information to the fault log after retry failure.

[0072] ③ State update broadcast. Based on the activated protocol type, perform differentiated broadcast process: If it is BACnet protocol, send the status update notification to all nodes subscribed to the lighting controller status in the BMS system through BACnet broadcast service (BBMD), the notification message contains object ID, new state value, check code and other core information, the broadcast period is 100 ms, and all subscribed nodes feedback confirmation until all subscribed nodes feedback confirmation; If it is KNX protocol, send the status telegram to the corresponding group address through KNX multicast mechanism (comply with KNX ETS standard telegram format, priority field set to "high priority"), the telegram content contains loop state data and CRC-16 check code, and listen to the bus feedback to ensure that the telegram sending success rate is ≥99.5%.

[0073] After the broadcast is completed, record the confirmation status of each receiving node to the unified state storage.

[0074] ④ Backup protocol buffer synchronization. If the system is configured with a backup protocol channel (such as the current active KNX protocol, and the backup is BACnet protocol), start the key state data synchronization process; extract the core state data (including all loop switch states, current dimming value, running scene ID, time table execution progress) from the unified state storage, and convert it according to the data format of the backup protocol - KNX group object state to BACnet binary output object / analog output object data; Synchronization uses "incremental synchronization" mechanism, only synchronize the state data that has changed or added after protocol switching, to avoid resource occupation caused by full synchronization; Synchronization data is stored in the local buffer area of the backup protocol transceiver unit (buffer area capacity ≥1MB, supports power-off buffer), and a buffer data index table is established, the index table contains data type, synchronization timestamp, validity identifier, to ensure that the cached data can be quickly located and called in subsequent switching; After the completion of buffer synchronization, send the "buffer ready" notification to the corresponding management system / field device through the backup protocol channel, to inform it that it can respond to the status query request at any time.

[0075] Step S6: Fault-tolerant degradation and state rollback. This step realizes autonomous degradation control in the network full break scene and state consistency calibration after network recovery, which is specifically implemented as: ① Degradation trigger and control handover. The protocol arbitration module continuously aggregates the health scores of each protocol channel. When all protocol channels have a health score below the preset threshold (configurable, default 50 points) for 3 consecutive monitoring periods (default 300 ms) and there is no trend of health score recovery for any protocol channel, the fault-tolerant degradation process is triggered. First, send a hardware-level control handover signal to switch the lighting control core from the "protocol control unit" to the "local logic execution engine", and at the same time set the "control mode identifier" to "local emergency mode" through the unified state memory, and record the degradation trigger timestamp, each protocol fault code (such as BACnet fault code 0x03 indicating network interruption, KNX fault code 0x05 indicating bus short circuit) to the fault log; then close the physical layer module of all protocol transceiver units and release system resources to ensure the real-time performance of local logic execution; ② Local control autonomous operation. After the local logic execution engine takes over control, it prioritizes loading the preset emergency control strategy; in non-emergency scenarios, it executes the preset schedule and local sensor linkage logic: obtain the current time through the built-in RTC, match the control rules in the schedule, and at the same time collect local sensor data (including analog signal, dry contact signal), when the trigger condition is met, automatically turn on the corresponding area lighting; During local control, all state changes (including manual emergency switch operation, sensor-triggered automatic control, time table-triggered state switching) are written in real time to the local change log partition of the unified state memory in the standardized format of "circuit ID-operation type-target state-timestamp-trigger source" (this partition uses a circular coverage mechanism, retaining the last 1000 change records, and key emergency operation records are marked as "permanent retention"); At the same time, the current control mode, trigger source and fault state are displayed in real time through the LCD panel of the human-computer interaction interface, and the red LED indicator light is always on to indicate "local emergency operation"; ③ State rollback and control right return. The protocol arbitration module still monitors the state of each protocol channel at a cycle of 100 ms / once during local control. When it is detected that the health score of any protocol channel is higher than the threshold (default 60 points) for 3 consecutive cycles, it is determined that the network has returned to normal, triggering the state rollback process. First, read the local change log in the unified state storage, extract all state change data during local control (from the degradation trigger timestamp to the current timestamp) through "timestamp filtering", and generate a "change state list". Using the differential synchronization mechanism, only the change data is converted according to the corresponding protocol format and sent to the upper management system / field device through the restored protocol channel. During synchronization, each sent change data waits for the receiver's confirmation response (timeout time set to 500 ms, and if it times out, it will be retried twice), ensuring that the synchronization success rate is ≥99.8%. After all the change data is synchronized, perform state consistency calibration: compare the current state feedback from the upper management system / field device with the final state of the local change log, and if there is a difference, use the local change log for secondary calibration. After calibration, update the "control mode identifier" of the unified state storage to "protocol control mode", send the control right handover signal, return the control right to the protocol control unit, reinitialize the standby protocol channel and synchronize the current state to the standby protocol buffer area. Finally, turn off the local control mode prompt, the LCD panel displays "protocol normal operation", and the red LED indicator light is turned off, completing the entire rollback and return process.

[0076] The application will be further described in detail below with reference to the accompanying drawings Fig. 1~Fig. 3 The application will be further described in detail below with reference to the accompanying drawings

[0077] Example 1: Typical implementation based on BACnet and KNX dual protocols This embodiment is the optimal implementation scheme, which is suitable for high-end intelligent building scenarios such as Class A office buildings, and realizes the collaborative operation of BMS centralized management and local distributed control.

[0078] 1. Hardware configuration The lighting controller features a 16-channel independent control loop design, with each loop supporting 20A load output. The multi-protocol communication module integrates a BACnet / IP Ethernet unit (using an STM32H743 processor, supporting the BACnet B-SS protocol stack) and a KNXTP1 bus unit (using an NCN5120 transceiver chip, compliant with the KNX TP1 standard). The unified state memory employs a redundant design of 128 MB NOR Flash + 8 GB SD card to ensure data storage reliability. The local logic execution engine incorporates a high-precision RTC chip (clock error ≤ 1 minute / month), supporting the connection of light sensors (0-10 V analog input) and human body sensors. The human-machine interface features a 2.4-inch LCD display panel and four function buttons.

[0079] 2. Software Implementation The system software adopts a layered architecture. The bottom layer is the hardware driver layer, which implements hardware adaptation for each module. The middle layer is the protocol stack layer, which integrates the BACnet B-SS protocol stack and the KNX protocol stack, supporting the mapping configuration between BACnet objects (such as analog input objects and binary output objects) and KNX group objects. The upper layer is the application layer, which implements core functions such as protocol arbitration, state synchronization, and local logic execution. KNX group address binding and parameter configuration are completed through KNX engineering tools, and BACnet debugging software is used to complete the integration and registration with the BMS.

[0080] 3. Workflow When the system is running normally, the primary protocol is configured as BACnet / IP. The upper-layer BMS sends control commands to the lighting controller via the BACnet protocol (such as turning on all office lights during working hours and dimming them to 80%). The protocol arbitration module monitors the BACnet channel communication quality in real time, and the health score is maintained above 90 points (out of 100). All status changes after the execution of commands are written to the unified status memory in real time and synchronized to the KNX group object mapping table to ensure that the status display of the local KNX smart panel and the sensor is consistent.

[0081] When a core switch failure causes a BACnet network outage, the protocol arbitration module detects that the BACnet channel response delay exceeds 500 ms, the bit error rate reaches 10%, and the health score drops to 55 points (below the preset threshold of 60 points), triggering the protocol switching process: the system completes a state snapshot backup within 80 ms, shuts down the BACnet protocol stack, activates the KNX protocol stack, and completes state synchronization based on the mapping relationship in the unified state memory; after the switch is completed, the local KNX smart panel and light sensor directly control the lighting circuit. For example, when the light intensity is below 300 lux, the auxiliary lighting in the window area is automatically turned on, and the user is unaware of the switch.

[0082] When the KNX bus is interrupted due to a line fault, the protocol arbitration module monitors that the KNX channel health score drops to 40 points, the system automatically switches to the local control mode, the local logic execution engine executes the control according to the preset schedule (such as automatically turning off the non-office area light at 18:00), and responds to the dry contact fire linkage signal (when the fire signal is triggered, the emergency lighting loop is turned on); during local control, the light state adjusted by the user through the manual emergency switch is recorded to the local change log in real time.

[0083] When the BACnet network and the KNX bus are both restored to normal, the system first synchronizes the change state during local control to the BMS and the KNX field device, completes the state consistency calibration, and then switches back to the BACnet main protocol mode to restore centralized management.

[0084] Example 2: Control method flow verification example Taking the 10-story lighting system of an intelligent park office building as an example, the reliability test is carried out after deploying the system of the application: Test scenario 1: during normal operation, the BMS controls all lighting loops on the 10th floor to be turned on through the BACnet protocol, the dimming value is 70%, and each KNX panel displays the same state as the BMS, with a state synchronization delay of ≤50ms.

[0085] Test scenario 2: disconnect the core switch to simulate BACnet network interruption, the system switches to the KNX protocol within 95ms, the local KNX panel can normally adjust the conference room light scene, and there is no flicker or extinction during the switching process.

[0086] Test scenario 3: cut off the KNX bus to simulate double network failure, the system switches to the local control mode, automatically turns off half of the corridor lights at 12:00 according to the preset schedule, and the response delay is ≤100ms.

[0087] Test scenario 4: restore network connection, the system automatically synchronizes the change of the corridor light state during local control to the BMS, the BMS state display is consistent with the field, and after synchronization is completed, it switches back to the BACnet protocol, and the whole process does not require manual intervention.

[0088] The test results show that the system of the application can realize seamless switching and state consistency of multiple protocols, and the fault tolerance degradation capability is reliable, which fully meets the lighting control needs of high-end intelligent buildings.

[0089] It is to be noted that, in the present text, relational terms such as first and second and the like can be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can include other elements not expressly listed or inherent to such process, method, article, or apparatus.

[0090] Finally, it should be noted that the above-mentioned only constitutes the preferred embodiments of the present application and is not intended to limit the present application. Although the present application has been described in detail with reference to the foregoing embodiments, it will be apparent to those skilled in the art that modifications, equivalent replacements, and improvements of the technical solutions described in the foregoing embodiments can be made. Any modifications, equivalent replacements, and improvements made within the spirit and principle of the present application shall fall within the scope of the present application.

Claims

1. An intelligent lighting control system based on multi-protocol dynamic switching, characterized in that, It includes a lighting controller, a multi-protocol communication module, a protocol arbitration module, a unified state memory, a local logic execution engine, and a human-machine interface. Each module interacts with the other via an internal high-speed bus.

2. The intelligent lighting control system based on multi-protocol dynamic switching as described in claim 1, characterized in that, The lighting controller has 8 to 16 independent control loops, each loop supports 16A / 20A high current load output, and is equipped with a manual emergency switch, dry contact input interface and overload, short circuit and over-temperature protection circuits. The load on / off status can be verified through the loop current detection module. The multi-protocol communication module adopts a modular hardware design, integrating at least two independent protocol transceiver units, which respectively support the parallel operation of the management layer protocol and the field layer protocol. The physical layers of each protocol unit are independent of each other. Each protocol transceiver unit is configured with an independent monitoring buffer area, which supports lock / unlock control of the receive buffer. The protocol arbitration module includes a communication quality monitoring subunit, a health assessment subunit, and a handover decision subunit; the communication quality monitoring subunit adopts a monitoring timing sequence of "polling + interruption combination" to collect multi-dimensional operating parameters of each protocol channel in real time. The health assessment subunit calculates the health score of each protocol based on a preset weighting algorithm; The switching decision subunit can perform atomic protocol switching operations, and can send hardware-level interrupt signals to intercept instructions and control the handover of control. The unified state memory adopts a redundant design of NOR Flash and SD card to build a unified state data model. It centrally stores the real-time state of the control loop, scenario configuration parameters, time schedule, protocol mapping table and fault log. It is divided into main storage area, backup area, local change log partition and monitoring log partition. It supports real-time writing of control state, snapshot backup and cyclic overwrite storage, and provides standardized data interface to ensure data read and write atomicity and consistency. The local logic execution engine has a built-in high-precision real-time clock, supports time schedule programming at the year / month / day / hour / minute level, and integrates logic function blocks such as AND / OR / NOT, delay, and threshold comparison; it has input interfaces for light and human body sensors, and can take over control and perform autonomous control when the network is abnormal; it supports fire linkage signal access, and in emergency scenarios, it prioritizes the execution of emergency lighting control logic and shields non-emergency commands. The human-machine interface includes a local LCD display panel, a button group, and a remote communication interface; the local panel can visually display the protocol operation status, circuit status, and fault information, and the button group supports protocol parameter configuration and manual control; the remote communication interface supports HTTP / JSON protocols, enabling remote configuration of multiple protocol parameters, status monitoring, and fault log reading.

3. The intelligent lighting control system based on multi-protocol dynamic switching as described in claim 1, characterized in that, The multi-protocol communication module supports BACnet / IP as the management layer protocol and KNX TP1 as the field layer protocol. The protocol transceiver unit is modularly designed and can be replaced with the corresponding protocol module as needed. The BACnet / IP unit supports the TCP / IP protocol stack and BACnet BBMD broadcast service, while the KNX TP1 unit uses the NCN5120 transceiver chip and supports bus voltage detection and multicast mechanism.

4. The intelligent lighting control system based on multi-protocol dynamic switching as described in claim 1, characterized in that, The health assessment subunit of the protocol arbitration module uses a weighted algorithm to calculate the health score, and the scoring formula is as follows: V Health =Σ( w i × f i ( x i ))× 100 ; For Ethernet protocols, monitor response latency, bit error rate, link persistence, signal strength, and retransmission count; for bus-type field layer protocols, additionally monitor bus voltage, telegraph error rate, group address communication success rate, and bus load rate. The weights and normalization functions for Ethernet protocol metrics parameters are as follows: The weights and normalization functions of the bus-type field layer protocol parameters are as follows: Based on the scoring results, the system state is divided, and the switching decision table is as follows: 。 5. The intelligent lighting control system based on multi-protocol dynamic switching as described in claim 1, characterized in that, The unified state memory's protocol mapping table is pre-configured with the correspondence between different protocol objects; it supports timestamp-based differential synchronization and state calibration. The sensor input interface of the local logic execution engine supports 0~10V analog signals and dry contact signals; the emergency control logic includes forcibly opening all emergency lighting circuits when fire linkage occurs, and executing timetable and sensor linkage logic in non-emergency scenarios. The LCD panel of the human-machine interface can display initialization results, protocol error information and current control mode; the fault log can record information such as hardware fault codes, protocol fault codes, switching timestamps, and degradation trigger reasons, and supports remote reading and local query.

6. A smart lighting control method based on multi-protocol dynamic switching, applied to the system described in any one of claims 1 to 5, characterized in that, Includes the following steps: Step S1: System initialization, execution of hierarchical verifiable process; Step S2: Protocol communication quality monitoring; Step S3: Protocol health assessment and handover triggering; Step S4: Seamless switching and state synchronization; Step S5: Command reception and status broadcast; Step S6: Fault tolerance degradation and state backtracking.

7. The intelligent lighting control method based on multi-protocol dynamic switching as described in claim 6, characterized in that, Step S1 specifically includes: ① Hardware minimum system self-test: scanning the connection status of the core module through GPIO pins; if abnormal, a red LED flashes as an alarm and a fault code is recorded; ② Reading the preset configuration parameters of the unified state memory; the parameters adopt the format of "main parameter + CRC-16 checksum"; if the check fails, the default configuration is loaded; ③ Initializing the multi-protocol stack: establishing network connections with the upper-level management system and field devices; if initialization fails, the channel is marked as abnormal and the backup protocol stack is used first; ④ Control loop continuity self-test: detecting the loop fault status and the initial status of the manual emergency switch, and writing the initial status data to the main storage area and the backup area; ⑤ Updating the system running status to "initialization complete" and recording the initialization time. Step S2 specifically includes the following: the protocol arbitration module collects multi-dimensional indicators of each protocol channel in a "polling + interruption combination" sequence, and collects signal strength, response delay, bit error rate, link persistence, and retransmission count for Ethernet protocols. For bus-type protocols, additional data such as bus voltage, telegraph error rate, group address communication success rate, and bus load rate are collected. The collected data is written to the monitoring log partition after outlier filtering and standardization. In case of anomalies, feedback is provided through the LCD panel and status indicator lights. Step S3 specifically includes the health assessment subunit calculating the health score of each protocol based on a preset weighting algorithm. When the health of the primary protocol is below the preset threshold for three consecutive monitoring cycles, and the health of the backup protocol is above the threshold, the protocol switching process is triggered. When the health of the primary protocol recovers to above the threshold and remains above it for 3 consecutive cycles, the switchback process is triggered. Step S4 specifically includes the following operations performed by the switching decision subunit: ① Sending a hardware-level interrupt signal to lock each protocol receive buffer and informing the outside world of the "switching in progress" status; ② Reading the core status data of the control loop through the DMA channel, generating a standardized status snapshot, and storing it in an independent backup partition after CRC-32 verification; ③ Performing atomic protocol stack switching, shutting down the primary protocol physical layer module and releasing resources, initializing the backup protocol parameters and loading the configuration file. ④ Based on the protocol mapping table, complete the cross-protocol conversion and batch synchronization of status data, and verify data consistency after synchronization; ⑤ Update the protocol running status identifier, unlock the buffer and clear the "switching in progress" flag; the entire process takes ≤100 ms; Step S5 specifically includes: ① Unlocking the protocol receive buffer, using a "gradient reception" mechanism to grant command reception permissions based on priority, updating the system operating status and recording the switching log; ② After receiving and executing control commands, verifying the actual status through the current detection module. If consistent, writing the data into the unified status memory in a standardized format; otherwise, triggering a retry mechanism; ③ Performing differentiated broadcasts based on the activation protocol to ensure consistent device status within the same network; ④ Incrementally synchronizing key status data to the backup protocol buffer and establishing an index table, and sending a "buffer ready" notification; Step S6 specifically includes: ① When the health of all protocol channels is below the threshold (default 50 points) for three consecutive monitoring cycles, fault tolerance degradation is triggered, a hardware-level control handover signal is sent to the local logic execution engine, the control mode is set to "local emergency mode", and the physical layer module of the protocol transceiver unit is shut down; ② The local logic execution engine loads the emergency control strategy, executes the timetable and sensor linkage logic, records all status changes to the local change log and prompts them through LCD and LED; ③ After any protocol channel is detected to have returned to normal, the local change log is extracted to generate a change list, which is synchronized to the corresponding system / device using a differential synchronization mechanism. After completing the status consistency calibration, the control is switched back to the protocol control unit, and the local emergency prompt is turned off.

8. The intelligent lighting control method based on multi-protocol dynamic switching as described in claim 7, characterized in that, The configuration parameters in step S1 include protocol type configuration, primary protocol priority weight, health assessment weight coefficient, switching threshold, and basic parameters of each protocol unit; the initialization time is ≤3 seconds by default; the outlier filtering in step S2 adopts the 3σ criterion, and the data standardization quantifies the indicators into a unified score of 0~100.

9. The intelligent lighting control method based on multi-protocol dynamic switching as described in claim 7, characterized in that, In step S2, the response latency of the BACnet / IP protocol is the average of the response times of three consecutive read requests, with a default threshold of ≤200 ms, a bit error rate threshold of ≤1%, and a retransmission count threshold of ≤3 times / cycle; the standard range of the bus voltage for the KNX TP1 protocol is 24 V ± 10%, the telegram error rate threshold is ≤2%, the group address communication success rate is ≥95%, and the bus load rate threshold is ≤30%; a hardware interrupt is immediately triggered when the bus voltage is abnormal.

10. The intelligent lighting control method based on multi-protocol dynamic switching as described in claim 7, characterized in that, The status snapshot in step S4 is 16 bytes / loop, including loop switch status, dimming parameters, running scene ID, and fault alarm status; batch synchronization is processed in batches of 8 loops; the broadcast period in step S5 is 100 ms, the KNX status telegram conforms to the ETS standard and is set to "high" priority, with a transmission success rate of ≥99.5%; the backup protocol buffer capacity is ≥1 MB and supports power failure buffering; And / or, the downgrade trigger judgment period in step S6 is 300 ms by default, and the local control status change log is recorded in the format of "loop ID-operation type-target status-timestamp-trigger source"; the synchronization response timeout for status backtracking is 500ms, and the system will retry twice if the timeout occurs, with a synchronization success rate of ≥99.8%; the status calibration is based on the local change log.

Images