Method for multi-platform cooperative control of DDC (Direct Digital Control) equipment

Abstract

The invention relates to the technical field of multi-platform control, in particular to a method for multi-platform cooperative control of DDC (Direct Digital Control) equipment, which comprises the following steps of: setting an operation mode logic controller and a switch control logic controller in a DDC controller; the operation mode logic controller defines an effective instruction range and synchronizes the effective instruction range to the switch control logic controller; the switch control logic controller filters invalid instructions according to the effective instruction range, arbitrates the effective instructions according to a priority rule and then outputs a unique control instruction; setting a manual instruction releasing mechanism; verifying the effectiveness of the control logic through a simulation multi-scene test; the method has the beneficial effects that through combination of mode identification and an instruction filtering mechanism, the problem of traditional permission solidification is solved, and flexible switching of control modes is realized; the control platform can be flexibly specified in different scenes, and the problem that a low-priority platform cannot intervene in control in an emergency is avoided.

Description

Technical Field

[0001] This invention relates to the field of multi-platform control technology, specifically a method for collaborative control of DDC devices across multiple platforms. Background Technology

[0002] In building automation systems, the DDC (Direct Digital Controller) serves as the core control unit, requiring control commands from different platforms to achieve precise control of building equipment. However, existing building control DDC commissioning technologies have the following shortcomings:

[0003] 1. Fixed permission levels lead to single-platform control problems: Traditional commissioning uses fixed priorities (such as Priority_Array in the BACnet standard). The building control system platform has the highest priority permissions and has control over DDC devices. Other lower priority platforms can only monitor the operating status of the devices but cannot control them, which makes it impossible to achieve cross-system linkage control and cannot meet the overall building's requirements for efficient, energy-saving and safe operation.

[0004] 2. Multi-platform control suffers from protocol-level control conflicts: The BACnet protocol standard (ANSI / ASHRAE 135-2020) does not define a multi-platform control arbitration mechanism. When the BA system platform and other system software (such as IBMS) have equal control priority and send WriteProperty commands simultaneously, the DDC only executes the last instruction in the order of receipt, which can easily lead to abnormal equipment operation. For example, in 2021, a complex in Shanghai experienced frequent start-ups and shutdowns of refrigeration units due to control conflicts, resulting in significant energy waste and equipment damage.

[0005] 3. Cumbersome modification of control rights on a single platform: Traditional DDC uses hard-coded binding to the control platform (such as the DDC_CTRL_LOCK parameter of JohnsonControls Metasys), which requires modification of control rights ownership through physical jumpers or dedicated configuration tools. According to actual test data from ASHRAE Guideline 13-2015, the switching time usually exceeds 30 minutes, which seriously affects the system response efficiency.

[0006] Therefore, there is an urgent need for a method to achieve conflict-free coordinated control of DDC controllers across multiple platforms in order to solve the aforementioned problems in the existing technology. Summary of the Invention

[0007] The purpose of this invention is to provide a method for multi-platform collaborative control of DDC devices, in order to solve the problem mentioned in the background art that the DDC devices do not support simultaneous control by building automation (BA) platforms and other platforms (such as IBMS systems), resulting in the IBMS platform being able to only monitor but not effectively control the DDC devices. At the same time, it overcomes the defects such as fixed permissions, limited mode switching, and control conflicts. By introducing a two-layer logic controller collaborative working mechanism, the orderly and reliable multi-platform control is achieved.

[0008] To achieve the above objectives, the present invention provides the following technical solution: a method for multi-platform collaborative control of DDC devices, comprising the following steps:

[0009] (1) Set up the operating mode logic controller and the switch control logic controller in the DDC controller;

[0010] (2) The operating mode logic controller defines the range of valid instructions and synchronizes them to the switch control logic controller;

[0011] (3) The switch control logic controller filters invalid instructions according to the range of valid instructions, and arbitrates the valid instructions according to the priority rules before outputting a unique control instruction;

[0012] (4) Set up a manual command cancellation mechanism;

[0013] (5) Verify the effectiveness of the control logic by simulating multiple scenarios.

[0014] Preferably, the operating mode logic controller includes a mode control register that stores mode identifier values ​​1, 2, and 3, corresponding to manual mode, BA automatic mode, and IBMS automatic mode, respectively; the switch control logic controller includes an instruction input register and an instruction arbitration unit, the instruction input register receiving BA manual instructions, IBMS manual instructions, BA automatic timetable instructions, and IBMS automatic timetable instructions.

[0015] Preferably, the operating mode logic controller defines the range of valid instructions through a mode identifier value, specifically:

[0016] When the mode identifier value is 1, only BA manual commands and IBMS manual commands are valid commands.

[0017] When the mode identifier value is 2, BA manual commands, IBMS manual commands, and BA automatic timetable commands are valid commands.

[0018] When the mode identifier value is 3, BA manual commands, IBMS manual commands, and IBMS automatic timetable commands are valid commands.

[0019] Preferably, the switch control logic controller synchronizes the defined range of valid instructions to itself and filters invalid instructions according to the range.

[0020] Preferably, the priority rule is that manual commands have higher priority than automatic timetable commands.

[0021] Preferably, when BA manual commands conflict with IBMS manual commands, the default priority shall prevail.

[0022] Preferably, the manual command release mechanism includes platform-initiated release, automatic release after timeout, and release via mode switching.

[0023] Preferably, the platform actively cancels the "manual command to clear" signal sent through the BA or IBMS platform.

[0024] Preferably, the test scenarios for the simulated multi-scenario test include mode switching, command conflict, and automatic recovery after manual command cancellation.

[0025] Preferably, the effectiveness of the control logic is verified by running the control logic under various simulated test scenarios and observing whether the response of the DDC device meets expectations.

[0026] Compared with the prior art, the beneficial effects of the present invention are:

[0027] The method for multi-platform collaborative control of DDC devices proposed in this invention solves the problem of traditional fixed permissions by combining mode identification and instruction filtering mechanisms, and realizes flexible switching of control modes. This allows for flexible designation of control platforms in different scenarios, avoiding the problem that low-priority platforms cannot intervene in control in emergency situations.

[0028] A dual-layer logic controller collaborative mechanism is adopted. The operation mode logic controller defines the control authority boundaries, while the switch control logic controller is responsible for command arbitration, thus avoiding multi-platform control conflicts from an architectural perspective. In manual mode, the BA platform or INMS platform can be operated, which is conducive to realizing cross-system linkage control and improving the overall building operation efficiency, energy saving effect and safety.

[0029] The manual command cancellation mechanism is diversified, supporting both manual intervention and automatic recovery, ensuring that the equipment can smoothly return to automatic control after temporary manual operation;

[0030] The debugging process covers core scenarios such as mode switching, instruction conflicts, and manual resolution, ensuring the reliability and security of control logic across multiple platforms. Attached Figure Description

[0031] Figure 1 This is a system architecture diagram of the multi-platform control DDC device of the present invention. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of the present invention clear and complete, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only some, not all, embodiments of the present invention, and are merely illustrative of the embodiments of the present invention. They are not intended to limit the embodiments of the present invention. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0033] Example 1: This invention provides a technical solution: a method for multi-platform collaborative control of a DDC device, which achieves collaborative control by setting an operating mode logic register and a switch control logic register within the DDC, specifically including the following steps:

[0034] In the DDC controller, a running mode logic register (data type Dword) is set up. This register is used to store mode identifier values ​​1, 2, and 3, which correspond to the three control modes respectively:

[0035] Number 1: Manual mode, allowing the device to be started and stopped via the BA platform or IBMS platform;

[0036] Number 2: BA automatic mode, the DDC device starts and stops the device according to the timetable in the BA platform;

[0037] Number 3: IBMS Automatic Mode, where DDC devices start and stop on a timed basis according to the schedule within the IBMS integrated platform.

[0038] Simultaneously, a switch control logic controller is set in the DDC controller, which includes an instruction input register and an instruction arbitration unit:

[0039] The instruction input register is used to receive four types of instruction signals: BA manual instruction (BA_MANUAL), IBMS manual instruction (IBMS_MANUAL), BA automatic timetable instruction (BA_AUTO), and IBMS automatic timetable instruction (IBMS_AUTO).

[0040] The command arbitration unit has built-in priority rules: manual commands (BA / IBMS) have higher priority than automatic timetable commands; when BA manual commands conflict with IBMS manual commands, the conflict can be resolved through preset priority (configurable).

[0041] Configure the communication interfaces of the BA platform and the IBMS integrated platform so that they can communicate with the DDC controller via the BACnet protocol to read and modify the values ​​in the mode logic register.

[0042] Mode control process:

[0043] The BA platform or IBMS integrated platform sends control commands containing the target mode identifier value to the DDC controller via the BACnet protocol to modify the value in the mode logic register.

[0044] The operating mode logic controller synchronizes the current mode identifier value to the switch control logic controller in real time, which serves as the basis for instruction filtering.

[0045] Command filtering and arbitration process:

[0046] The switch control logic controller filters input commands based on the received mode identifier value:

[0047] When the mode flag is 1 (manual mode): only BA_MANUAL and IBMS_MANUAL instructions are allowed to enter the arbitration unit, and BA_AUTO and IBMS_AUTO instructions are disabled;

[0048] When the mode identifier is 2 (BA automatic mode): BA_MANUAL, IBMS_MANUAL, and BA_AUTO instructions are allowed to enter the arbitration unit, while IBMS_AUTO is disabled;

[0049] When the mode is set to 3 (IBMS Automatic Mode): BA_MANUAL, IBMS_MANUAL, and IBMS_AUTO commands are allowed to enter the arbitration unit, while BA_AUTO is disabled.

[0050] The instruction arbitration unit arbitrates the filtered valid instructions according to the priority rules and outputs a unique control instruction (1 = on, 0 = off) to the DDC execution mechanism.

[0051] Manual command cancellation mechanism:

[0052] Platform-initiated cancellation: Send a "manual command to clear" signal (e.g., BA_MANUAL = NULL) through the BA / IBMS platform;

[0053] Automatic cancellation upon timeout: The preset validity period of manual commands will be automatically cleared by the switch control logic controller after the timeout.

[0054] Mode switching deactivation: When the mode is switched from 1 (manual) to 2 or 3, all manual commands are automatically cleared.

[0055] Debugging and verification process:

[0056] In modes 1, 2, and 3 respectively, conflicting commands were sent from multiple platforms to verify the effectiveness of the filtering and arbitration of the switch control logic controller.

[0057] Smooth transition of device status during test mode switching (without sudden start-stop);

[0058] Verify whether the device correctly resumes automatic control after the manual command is released.

[0059] Example 2, based on Example 1, proposes the following:

[0060] This embodiment uses the DDC control of an air conditioning system in a commercial complex as an example to illustrate the method of multi-platform collaborative control of DDC equipment of the present invention.

[0061] Controller hardware configuration:

[0062] Select a programmable DDC controller that supports the BACnetIP protocol;

[0063] The mode control register address of the operating mode logic controller is set to 0x0001 (Dword type);

[0064] Address allocation of instruction input registers for the switch control logic controller:

[0065] BA_MANUAL: 0x0002 (Boolean, 1 = On, 0 = Off, NULL = Disabled)

[0066] IBMS_MANUAL: 0x0003 (Boolean)

[0067] BA_AUTO: 0x0004 (Boolean)

[0068] IBMS_AUTO: 0x0005 (Boolean)

[0069] The instruction arbitration unit output address is 0x0006 (Boolean type, directly driving the air conditioner contactor).

[0070] Mode 1 (Manual Mode) Debugging Procedure:

[0071] Send a mode switching instruction through the BA platform to set the value of register 0x0001 to 1;

[0072] Verification command filtering: BA_AUTO=1 is sent from the BA platform and IBMS_AUTO=1 is sent from the IBMS platform. The DDC configuration tool detects that the values ​​of 0x0004 and 0x0005 are not received by the switch control logic controller.

[0073] Verification instruction arbitration:

[0074] Send BA_MANUAL=1 and IBMS_MANUAL=0, and detect 0x0006 output=1 (execute BA instruction);

[0075] Sending BA_MANUAL=0 and IBMS_MANUAL=1, the output 0x0006 is detected as 0 (the BA instruction is executed because the default BA manual priority is higher).

[0076] d. Verify manual release: Send BA_MANUAL=NULL from the BA platform, detect 0x0002=NULL, and keep the last state at 0x0006 (because there is no automatic instruction).

[0077] Debugging process for Mode 2 (BA Automatic Mode):

[0078] Send a mode switching instruction through the BA platform to set the value of register 0x0001 to 2;

[0079] Configure BA automatic timetable: BA_AUTO = 1 for weekdays 8:00-18:00, and 0 for other times;

[0080] Simulate normal automatic operation: At 9:00, it was detected that BA_AUTO=1, no manual instruction was given, and 0x0006 output=1;

[0081] Simulated manual intervention: At 10:00, IBMS_MANUAL=0 was sent from the IBMS platform, and 0x0006 output=0 was detected (manual command takes precedence);

[0082] Simulated manual release: At 11:00, IBMS_MANUAL=NULL was sent from the IBMS platform, and 0x0006 output=1 was detected (BA_AUTO control was restored).

[0083] Mode 3 (IBMS Automatic Mode) Debugging Procedure:

[0084] Send a mode switching instruction via the IBMS platform to set the value of register 0x0001 to 3;

[0085] Configure IBMS automatic timetable: IBMS_AUTO = 1 for holidays 9:00-16:00, and 0 for other times;

[0086] Simulated timeout release: At 10:00, BA_MANUAL=1 (setting validity period of 1 hour) is sent from the BA platform, and 0x0006 output=1 is detected; it is automatically released at 11:00, 0x0002=NULL, and 0x0006 output=1 (IBMS_AUTO is still valid).

[0087] Mode switching debugging process:

[0088] Switch from Mode 2 to Mode 3:

[0089] At 17:50, BA_AUTO = 1 (before 18:00), a mode switching command was sent;

[0090] During the switching transition period (30 seconds), the output 0x0006 remained at 1.

[0091] After the switch is completed (0x0001 = 3), IBMS_AUTO = 0 (not a holiday), and 0x0006 output = 0 (smooth transition).

[0092] Conflict alarm debugging:

[0093] In mode 1, both BA_MANUAL=1 and IBMS_MANUAL=0 are sent simultaneously.

[0094] The system detected that the DDC sent a "manual command conflict" alarm (including details of the conflicting command) to both platforms via the BACnet protocol.

[0095] The above debugging process verified the effectiveness of the collaborative work between the operating mode logic controller and the switch control logic controller, ensuring that control commands from multiple platforms can be executed without conflict in various scenarios.

[0096] Example 3, based on Example 2, proposes a system for controlling DDC devices across multiple platforms. The system architecture diagram is as follows. Figure 1 As shown, Figure 1 In the diagram, 1 represents the BA platform, 2 represents the IBMS integrated platform, 3 represents the DDC controller, 4 represents the mode logic register, 5 represents the switch control logic register, 6 represents the switch control association register, and 7 represents the controlled electromechanical equipment (such as an air conditioner).

[0097] Both BA platform 1 and IBMS integrated platform 2 communicate with DDC controller 3 via BACnet protocol. DDC controller 3 has a mode logic register 4 and a switch logic register inside. The platform sends mode switching instructions to DDC controller 3 via BACnet protocol, modifies the value of the running mode logic register 4, and synchronizes it in real time to the instruction arbitration area of ​​switch control logic register 5. The switch control logic register 6 filters the instructions and outputs a unique instruction to the switch association register, and controls the operation of the controlled electromechanical equipment 7 through the DDC actuator.

[0098] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for multi-platform collaborative control of a DDC device, the method comprising: The method comprises the following steps: ​ (1) setting a running mode logic controller and a switch control logic controller in a DDC controller; (2) defining an effective instruction range by the running mode logic controller and synchronizing to the switch control logic controller; (3) filtering invalid instructions by the switch control logic controller according to the effective instruction range, arbitrating the effective instructions according to a priority rule and outputting a unique control instruction; (4) setting a manual instruction canceling mechanism; (5) verifying the effectiveness of the control logic by simulating multiple scene tests.

2. The method of claim 1, wherein: The running mode logic controller comprises a mode control register storing mode identification values 1, 2 and 3 corresponding to manual mode, BA automatic mode and IBMS automatic mode respectively; and the switch control logic controller comprises an instruction input register and an instruction arbitration unit, the instruction input register receiving BA manual instruction, IBMS manual instruction, BA automatic schedule instruction and IBMS automatic schedule instruction.

3. The method of claim 1, wherein: The running mode logic controller defines the effective instruction range by the mode identification values, specifically: when the mode identification value is 1, only BA manual instruction and IBMS manual instruction are effective instructions; when the mode identification value is 2, BA manual instruction, IBMS manual instruction and BA automatic schedule instruction are effective instructions; when the mode identification value is 3, BA manual instruction, IBMS manual instruction and IBMS automatic schedule instruction are effective instructions.

4. The method of claim 1, wherein: The switch control logic controller synchronizes the defined effective instruction range to itself and filters invalid instructions according to the range.

5. The method of claim 1, wherein: The priority rule is that the priority of manual instruction is higher than that of automatic schedule instruction.

6. The method of claim 5, wherein: When BA manual instruction and IBMS manual instruction conflict, the preset priority is used for arbitration.

7. The method of claim 1, wherein: The manual instruction canceling mechanism comprises platform active canceling, timeout automatic canceling and mode switching canceling.

8. The method of claim 7, wherein: The platform active canceling sends a "manual instruction zero clearing" signal by BA or IBMS platform.

9. The method of claim 1, wherein: The test scenes of the simulated multiple scene tests include mode switching, instruction conflict and automatic recovery after manual instruction canceling.

10. The method of claim 9, wherein: The effectiveness of the control logic is verified by running the control logic under the simulated test scenes and observing whether the response of the DDC device is as expected.

Images