SYSTEMS AND METHODS FOR AUTOMATICALLY CONFIGURING AN IP NETWORK

BACKGROUND

The present disclosure relates generally to a building automation system (BAS). The present disclosure relates more particularly to automated design and configuration of an Internet Protocol (IP) network for a BAS.

A BAS is, in general, a system of devices configured to control, monitor, and manage equipment in or around a building or building area. A BAS can include, for example, a HVAC system, a security system, a lighting system, a fire alerting system, any other system that is capable of managing building functions or devices, or any combination thereof. A BAS can include various types of building equipment (e.g., chillers, fans, valves, dampers, etc.) that operate to control conditions within a building space.

Traditionally, the BAS is a Master Slave Token Passing (MS/TP) protocol based system, and the majority of the devices in the BAS are connected using the MS/TP networks. With the ubiquity of the Internet and the Internet Protocol in modern communications, it is advantageous for the BAS to evolve into an Internet Protocol (IP) based system. However, configuring an IP network for the BAS is not a trivial task. For example, while proficient at designing, deploying, and commissioning HVAC systems, BAS field personnel may not be well-versed in IP systems or Information Technology (IT) in general. As another example, the configuration file for a managed switch is typically hundreds of lines long and can include complicated commands. Thus, each misconfigured line in a switch configuration file can be a potential field problem. Accordingly, it would be beneficial to automate the design and configuration of an IP network for the BAS.

SUMMARY

In the present disclosure, an IP network for the BAS may be referred to as an operational technology (OT) network, in some embodiments. Such terminology is used to compare and contrast the BAS IP network (OT network) with networks designed for information technology (IT), in some embodiments.

One implementation of the present disclosure is a system for automatically configuring an Internet Protocol (IP) network. The system can include a memory and a processor coupled to the memory. The processor can be configured to receive inputs comprising information specific to a building automation system (BAS) and information specific to the IP network. The processor can be configured to identify a plurality of network controllers and identify, for each of the identified plurality of network controllers, a respective plurality of BAS devices supervised by the network controller based on the received inputs. The processor can also be configured to allocate, for each of the identified plurality of network controllers, the respective plurality of BAS devices supervised by the network controller to one or more subnets and one or more access switches. The processor can further be configured to consolidate at least two subnets under the same switch responsive to determining that the at least two subnets can be consolidated under the same switch. The processor can be configured to perform IP planning for the IP network and generate a configuration file tailored for each access switch in the IP network.

In some embodiments, the processor can be configured to determine whether an aggregation switch is to be included in the IP network. The processor can further be configured to generate, responsive to determining that the aggregation switch is to be included, a tailored configuration file for the aggregation switch.

In some embodiments, the processor can be configured to generate an installation file indicating (i) how the BAS devices are to be connected to the access switches, (ii) how an access switch is to be connected to another access switch, an IT network switch, and/or an aggregation switch, (iii) required configuration of static IP addresses in the network controllers, and (iv) configuration changes required to the IT network.

In some embodiments, the processor can be configured to determine whether a list of individual devices, a list of groups of devices, or high level inputs are specified based on the received inputs. Responsive to the list of individual devices being specified, the processor can be configured to determine, for each network controller in the list of individual devices, a number of BAS devices supervised by the network controller and how each BAS device supervised by the network controller is connected to the IP network. Responsive to the list of groups of devices being specified, the processor can be configured to identify the plurality of network controllers by identifying a supervising network controller in each group of the list of groups. Each group includes the respective supervising network controller and a plurality of BAS devices supervised by the respective supervising network controller, devices in each group shares a same Ethernet connectivity method. Responsive to the high level inputs being specified, the processor can be configured to determine a number of network switches to be used in the IP network and distribute a plurality of BAS devices across the network switches based on how the plurality of BAS devices are connected to the IP network.

In some embodiments, the processor can be configured to perform IP planning by determining a respective subnet to which each network controller is to be assigned, reserving and assigning a static address to each network controller, and reserving dynamic IP addresses for specific devices or allocated for groups of devices.

In some embodiments, the configuration file for each access switch can include information of a respective Dynamic Host Configuration Protocol (DHCP) server for each subnet in the IP network allocated to each access switch.

In some embodiments, the configuration file for each access switch can include a configuration for each physical switch port on the access switch, one or more access control lists for the access switch, and information indicating how messages are routed in order to reach destinations of the messages.

In some embodiments, the processor can be configured to determine, for each access switch, whether the access switch supports an external media interface associated with an external media. The processor can further be configured to, responsive to the access switch supporting an external media interface, generate and store content on the external media for the access switch.

In some embodiments, the processor can be configured to calculate a total number of network switches required for the IP network, and generate a bill of materials for required network infrastructure of the IP network.

Another implementation of the present disclosure is a method for automatically configuring an Internet Protocol (IP) network. The method includes receiving, by a processing circuit, inputs comprising information specific to a building automation system (BAS) and information specific to the IP network. The method includes identifying, by the processing circuit, a plurality of network controllers and identifying, for each of the identified plurality of network controllers, a respective plurality of BAS devices supervised by the network controller based on the received inputs. The method further includes allocating, for each of the identified plurality of network controllers, the respective plurality of BAS devices supervised by the network controller to one or more subnets and one or more access switches. The method also includes consolidating at least two subnets under the same switch responsive to determining that the at least two subnets can be consolidated under the same switch. The method includes performing IP planning for the IP network and generating a configuration file tailored for each access switch in the IP network.

In some embodiments, the method includes determining whether an aggregation switch is to be included in the IP network. The method also includes generating, responsive to determining that the aggregation switch is to be included, a tailored configuration file for the aggregation switch.

In some embodiments, the method includes generating an installation file indicating (i) how the BAS devices are to be connected to the access switches, (ii) how an access switch is to be connected to another access switch, an IT network switch, and/or an aggregation switch, (iii) required configuration of static IP addresses in the network controllers, and (iv) configuration changes required to the IT network.

In some embodiments, the method includes determining whether a list of individual devices, a list of groups of devices, or high level inputs are specified based on the received inputs. The method includes, responsive to the list of individual devices being specified, determining, for each network controller, a number of BAS devices supervised by the network controller and how each BAS device supervised by the network controller is connected to the IP network. The method further includes, responsive to the list of groups of devices being specified, identifying the plurality of network controllers by identifying a supervising network controller in each group of the list of groups. Each group includes the respective supervising network controller and a plurality of BAS devices supervised by the respective supervising network controller, and devices in each group shares a same Ethernet connectivity method. The method also includes, responsive to the high level inputs being specified, determining a number of network switches to be used in the IP network and distributing a plurality of BAS devices across the network switches based on how the plurality of BAS devices are connected to the IP network.

In some embodiments, the method includes determining a respective subnet to which each network controller is to be assigned, and reserving and assigning a static address to each network controller.

In some embodiments, the method includes determining, for each access switch, whether the access switch supports an external media interface associated with an external media. The method further includes, responsive to the access switch supporting an external media interface, generating and storing content on the external media for the access switch.

In some embodiments, the method includes calculating a total number of network switches required for the IP network, and generating a bill of materials for required network infrastructure of the IP network.

One implementation of the present disclosure is a non-transitory computer-readable medium. The non-transitory computer-readable medium stores computer-executable instructions that when executed by at least one processor, causing the at least one processor to perform operations for automatically configuring an Internet Protocol (IP) network. The operations include receiving inputs comprising information specific to a building automation system (BAS) and information specific to the IP network. The operations include identifying a plurality of network controllers and identifying, for each of the identified plurality of network controllers, a respective plurality of BAS devices supervised by the network controller based on the received inputs. The operations include allocating, for each of the identified plurality of network controllers, the respective plurality of BAS devices supervised by the network controller to one or more subnets and one or more access switches. The operations include consolidating at least two subnets under the same switch responsive to determining that the at least two subnets can be consolidated under the same switch. The operations include performing IP planning for the IP network and generating a configuration file tailored for each access switch in the IP network.

In some embodiments, the operations include determining whether an aggregation switch is to be included in the IP network. The operations include generating, responsive to determining that the aggregation switch is to be included, a tailored configuration file for the aggregation switch.

In some embodiments, the operations include generating an installation file indicating (i) how the BAS devices are to be connected to the access switches, (ii) how an access switch is to be connected to another access switch, an IT network switch, and/or an aggregation switch, (iii) required configuration of static IP addresses in the network controllers, and (iv) configuration changes required to the IT network.

In some embodiments, the operations include whether a list of individual devices, a list of groups of devices, or high level inputs are specified based on the received inputs. The operations include, responsive to the list of individual devices being specified, determining, for each network controller, a number of BAS devices supervised by the network controller and how each BAS device supervised by the network controller is connected to the IP network. The operations include, responsive to the list of groups of devices being specified, identifying the plurality of network controllers by identifying a supervising network controller in each group of the list of groups. Each group includes the respective supervising network controller and a plurality of BAS devices supervised by the respective supervising network controller, and devices in each group shares a same Ethernet connectivity method. The operations include, responsive to the high level inputs being specified, determining a number of network switches to be used in the IP network and distributing a plurality of BAS devices across the network switches based on how the plurality of BAS devices are connected to the IP network.

In some embodiments, the operations include determining a respective subnet to which each network controller is to be assigned and assigning a static address to each network controller.

In some embodiments, the operations include determining, for each access switch, whether the access switch supports an external media interface associated with an external media. The operations include, responsive to the access switch supporting an external media interface, generating and storing content on the external media for the access switch.

In some embodiments, the operations include calculating a total number of network switches required for the IP network, and generating a bill of materials for required network infrastructure of the IP network.

Those skilled in the art will appreciate that the summary is illustrative only and is not intended to be in any way limiting. Other aspects, inventive features, and advantages of the devices and/or processes described herein, as defined solely by the claims, will become apparent in the detailed description set forth herein and taken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings are not intended to be drawn to scale. Like reference numbers and designations in the various drawings indicate like elements. For purposes of clarity, not every component may be labeled in every drawing. In the drawings:

FIG. 1 is a drawing of a building equipped with a BAS which includes a HVAC system, according to an exemplary embodiment.

FIG. 2 is a block diagram of a waterside system which can be used to serve the building of FIG. 1, according to an exemplary embodiment.

FIG. 3 is a block diagram of an airside system which can be used to serve the building of FIG. 1, according to an exemplary embodiment.

FIG. 4 is a block diagram of a BAS which can be used to monitor and control the building of FIG. 1, according to an exemplary embodiment.

FIG. 5 is a block diagram of a system which can be used to interconnect networks within the building of FIG. 1, according to an exemplary embodiment.

FIG. 6A is a flow diagram illustrating a technique which can be used to interconnect networks within the building of FIG. 1, according to an exemplary embodiment.

FIG. 6B is a flow diagram continuing the process of FIG. 6A, according to some embodiments.

FIG. 7 is a schematic diagram of an isolated OT network to be used by the interconnecting network tool of FIG. 5 , according to an exemplary embodiment.

FIG. 8 is a schematic diagram illustrating an OT network interconnected to an IT network, according to an exemplary embodiment.

FIG. 9 is a block diagram illustrating a system for automatically configuring an IP network, according to an exemplary embodiment.

FIG. 10 is a block diagram illustrating an example device for automatically configuring an IP network, according to an exemplary embodiment.

FIG. 11 is a block diagram illustrating an example high level IP based BAS system configured using the IP network design and configuration tool, according to an exemplary embodiment.

FIG. 12A is a flow diagram of a process for automatically configuring an IP network, according to an exemplary embodiment.

FIG. 12B is a flow diagram continuing the process of FIG. 12A for automatically configuring an IP network, according to an exemplary embodiment.

DETAILED DESCRIPTION

Following below are more detailed descriptions of various concepts related to, and implementations of systems, methods, and apparatuses for automated design and configuration of an IP network. Before turning to the more detailed descriptions and figures, which illustrate the exemplary embodiments in detail, it should be understood that the application is not limited to the details or methodology set forth in the descriptions or illustrated in the figures. It should also be understood that the terminology is for the purpose of description only and should not be regarded as limiting.

Building Automation System and HVAC System

Referring now to FIGS. 1-4, an exemplary building automation system (BAS) and HVAC system in which the systems and methods of the present invention may be implemented are shown, according to an exemplary embodiment. Referring particularly to FIG. 1, a perspective view of a building 10 is shown. Building 10 is served by a BAS. A BAS is, in general, a system of devices configured to control, monitor, and manage equipment in or around a building or building area. A BAS can include, for example, a HVAC system, a security system, a lighting system, a fire alerting system, any other system that is capable of managing building functions or devices, or any combination thereof.

The BAS that serves building 10 includes an HVAC system 100. HVAC system 100 may include a plurality of HVAC devices (e.g., heaters, chillers, air handling units, pumps, fans, thermal energy storage, etc.) configured to provide heating, cooling, ventilation, or other services for building 10. For example, HVAC system 100 is shown to include a waterside system 120 and an airside system 130. Waterside system 120 may provide a heated or chilled fluid to an air handling unit of airside system 130. Airside system 130 may use the heated or chilled fluid to heat or cool an airflow provided to building 10. An exemplary waterside system and airside system which may be used in HVAC system 100 are described in greater detail with reference to FIGS. 2-3.

HVAC system 100 is shown to include a chiller 102, a boiler 104, and a rooftop air handling unit (AHU) 106. Waterside system 120 may use boiler 104 and chiller 102 to heat or cool a working fluid (e.g., water, glycol, etc.) and may circulate the working fluid to AHU 106. In various embodiments, the HVAC devices of waterside system 120 may be located in or around building 10 (as shown in FIG. 1) or at an offsite location such as a central plant (e.g., a chiller plant, a steam plant, a heat plant, etc.). The working fluid may be heated in boiler 104 or cooled in chiller 102, depending on whether heating or cooling is required in building 10. Boiler 104 may add heat to the circulated fluid, for example, by burning a combustible material (e.g., natural gas) or using an electric heating element. Chiller 102 may place the circulated fluid in a heat exchange relationship with another fluid (e.g., a refrigerant) in a heat exchanger (e.g., an evaporator) to absorb heat from the circulated fluid. The working fluid from chiller 102 and/or boiler 104 may be transported to AHU 106 via piping 108.

AHU 106 may place the working fluid in a heat exchange relationship with an airflow passing through AHU 106 (e.g., via one or more stages of cooling coils and/or heating coils). The airflow may be, for example, outside air, return air from within building 10, or a combination of both. AHU 106 may transfer heat between the airflow and the working fluid to provide heating or cooling for the airflow. For example, AHU 106 may include one or more fans or blowers configured to pass the airflow over or through a heat exchanger containing the working fluid. The working fluid may then return to chiller 102 or boiler 104 via piping 110.

Airside system 130 may deliver the airflow supplied by AHU 106 (i.e., the supply airflow) to building 10 via air supply ducts 112 and may provide return air from building 10 to AHU 106 via air return ducts 114. In some embodiments, airside system 130 includes multiple variable air volume (VAV) units 116. For example, airside system 130 is shown to include a separate VAV unit 116 on each floor or zone of building 10. VAV units 116 may include dampers or other flow control elements that can be operated to control an amount of the supply airflow provided to individual zones of building 10. In other embodiments, airside system 130 delivers the supply airflow into one or more zones of building 10 (e.g., via supply ducts 112) without using intermediate VAV units 116 or other flow control elements. AHU 106 may include various sensors (e.g., temperature sensors, pressure sensors, etc.) configured to measure attributes of the supply airflow. AHU 106 may receive input from sensors located within AHU 106 and/or within the building zone and may adjust the flow rate, temperature, or other attributes of the supply airflow through AHU 106 to achieve setpoint conditions for the building zone.

Referring now to FIG. 2, a block diagram of a waterside system 200 is shown, according to an exemplary embodiment. In various embodiments, waterside system 200 may supplement or replace waterside system 120 in HVAC system 100 or may be implemented separate from HVAC system 100. When implemented in HVAC system 100, waterside system 200 may include a subset of the HVAC devices in HVAC system 100 (e.g., boiler 104, chiller 102, pumps, valves, etc.) and may operate to supply a heated or chilled fluid to AHU 106. The HVAC devices of waterside system 200 may be located within building 10 (e.g., as components of waterside system 120) or at an offsite location such as a central plant.

In FIG. 2, waterside system 200 is shown as a central plant having a plurality of subplants 202-212. Subplants 202-212 are shown to include a heater subplant 202, a heat recovery chiller subplant 204, a chiller subplant 206, a cooling tower subplant 208, a hot thermal energy storage (TES) subplant 210, and a cold thermal energy storage (TES) subplant 212. Subplants 202-212 consume resources (e.g., water, natural gas, electricity, etc.) from utilities to serve the thermal energy loads (e.g., hot water, cold water, heating, cooling, etc.) of a building or campus. For example, heater subplant 202 may be configured to heat water in a hot water loop 214 that circulates the hot water between heater subplant 202 and building 10. Chiller subplant 206 may be configured to chill water in a cold water loop 216 that circulates the cold water between chiller subplant 206 building 10. Heat recovery chiller subplant 204 may be configured to transfer heat from cold water loop 216 to hot water loop 214 to provide additional heating for the hot water and additional cooling for the cold water. Condenser water loop 218 may absorb heat from the cold water in chiller subplant 206 and reject the absorbed heat in cooling tower subplant 208 or transfer the absorbed heat to hot water loop 214. Hot TES subplant 210 and cold TES subplant 212 may store hot and cold thermal energy, respectively, for subsequent use.

Hot water loop 214 and cold water loop 216 may deliver the heated and/or chilled water to air handlers located on the rooftop of building 10 (e.g., AHU 106) or to individual floors or zones of building 10 (e.g., VAV units 116). The air handlers push air past heat exchangers (e.g., heating coils or cooling coils) through which the water flows to provide heating or cooling for the air. The heated or cooled air may be delivered to individual zones of building 10 to serve the thermal energy loads of building 10. The water then returns to subplants 202-212 to receive further heating or cooling.

Although subplants 202-212 are shown and described as heating and cooling water for circulation to a building, it is understood that any other type of working fluid (e.g., glycol, CO2, etc.) may be used in place of or in addition to water to serve the thermal energy loads. In other embodiments, subplants 202-212 may provide heating and/or cooling directly to the building or campus without requiring an intermediate heat transfer fluid. These and other variations to waterside system 200 are within the teachings of the present invention.

Each of subplants 202-212 may include a variety of equipment configured to facilitate the functions of the subplant. For example, heater subplant 202 is shown to include a plurality of heating elements 220 (e.g., boilers, electric heaters, etc.) configured to add heat to the hot water in hot water loop 214. Heater subplant 202 is also shown to include several pumps 222 and 224 configured to circulate the hot water in hot water loop 214 and to control the flow rate of the hot water through individual heating elements 220. Chiller subplant 206 is shown to include a plurality of chillers 232 configured to remove heat from the cold water in cold water loop 216. Chiller subplant 206 is also shown to include several pumps 234 and 236 configured to circulate the cold water in cold water loop 216 and to control the flow rate of the cold water through individual chillers 232.

Heat recovery chiller subplant 204 is shown to include a plurality of heat recovery heat exchangers 226 (e.g., refrigeration circuits) configured to transfer heat from cold water loop 216 to hot water loop 214. Heat recovery chiller subplant 204 is also shown to include several pumps 228 and 230 configured to circulate the hot water and/or cold water through heat recovery heat exchangers 226 and to control the flow rate of the water through individual heat recovery heat exchangers 226. Cooling tower subplant 208 is shown to include a plurality of cooling towers 238 configured to remove heat from the condenser water in condenser water loop 218. Cooling tower subplant 208 is also shown to include several pumps 240 configured to circulate the condenser water in condenser water loop 218 and to control the flow rate of the condenser water through individual cooling towers 238.

Hot TES subplant 210 is shown to include a hot TES tank 242 configured to store the hot water for later use. Hot TES subplant 210 may also include one or more pumps or valves configured to control the flow rate of the hot water into or out of hot TES tank 242. Cold TES subplant 212 is shown to include cold TES tanks 244 configured to store the cold water for later use. Cold TES subplant 212 may also include one or more pumps or valves configured to control the flow rate of the cold water into or out of cold TES tanks 244.

In some embodiments, one or more of the pumps in waterside system 200 (e.g., pumps 222, 224, 228, 230, 234, 236, and/or 240) or pipelines in waterside system 200 include an isolation valve associated therewith. Isolation valves may be integrated with the pumps or positioned upstream or downstream of the pumps to control the fluid flows in waterside system 200. In various embodiments, waterside system 200 may include more, fewer, or different types of devices and/or subplants based on the particular configuration of waterside system 200 and the types of loads served by waterside system 200.

Referring now to FIG. 3, a block diagram of an airside system 300 is shown, according to an exemplary embodiment. In various embodiments, airside system 300 may supplement or replace airside system 130 in HVAC system 100 or may be implemented separate from HVAC system 100. When implemented in HVAC system 100, airside system 300 may include a subset of the HVAC devices in HVAC system 100 (e.g., AHU 106, VAV units 116, ducts 112-114, fans, dampers, etc.) and may be located in or around building 10. Airside system 300 may operate to heat or cool an airflow provided to building 10 using a heated or chilled fluid provided by waterside system 200.

In FIG. 3, airside system 300 is shown to include an economizer-type air handling unit (AHU) 302. Economizer-type AHUs vary the amount of outside air and return air used by the air handling unit for heating or cooling. For example, AHU 302 may receive return air 304 from building zone 306 via return air duct 308 and may deliver supply air 310 to building zone 306 via supply air duct 312. In some embodiments, AHU 302 is a rooftop unit located on the roof of building 10 (e.g., AHU 106 as shown in FIG. 1) or otherwise positioned to receive both return air 304 and outside air 314. AHU 302 may be configured to operate exhaust air damper 316, mixing damper 318, and outside air damper 320 to control an amount of outside air 314 and return air 304 that combine to form supply air 310. Any return air 304 that does not pass through mixing damper 318 may be exhausted from AHU 302 through exhaust damper 316 as exhaust air 322.

Each of dampers 316-320 may be operated by an actuator. For example, exhaust air damper 316 may be operated by actuator 324, mixing damper 318 may be operated by actuator 326, and outside air damper 320 may be operated by actuator 328. Actuators 324-328 may communicate with an AHU controller 330 via a communications link 332. Actuators 324-328 may receive control signals from AHU controller 330 and may provide feedback signals to AHU controller 330. Feedback signals may include, for example, an indication of a current actuator or damper position, an amount of torque or force exerted by the actuator, diagnostic information (e.g., results of diagnostic tests performed by actuators 324-328), status information, commissioning information, configuration settings, calibration data, and/or other types of information or data that may be collected, stored, or used by actuators 324-328. AHU controller 330 may be an economizer controller configured to use one or more control algorithms (e.g., state-based algorithms, extremum seeking control (ESC) algorithms, proportional-integral (PI) control algorithms, proportional-integral-derivative (PID) control algorithms, model predictive control (MPC) algorithms, feedback control algorithms, etc.) to control actuators 324-328.

Still referring to FIG. 3, AHU 302 is shown to include a cooling coil 334, a heating coil 336, and a fan 338 positioned within supply air duct 312. Fan 338 may be configured to force supply air 310 through cooling coil 334 and/or heating coil 336 and provide supply air 310 to building zone 306. AHU controller 330 may communicate with fan 338 via communications link 340 to control a flow rate of supply air 310. In some embodiments, AHU controller 330 controls an amount of heating or cooling applied to supply air 310 by modulating a speed of fan 338.

Cooling coil 334 may receive a chilled fluid from waterside system 200 (e.g., from cold water loop 216) via piping 342 and may return the chilled fluid to waterside system 200 via piping 344. Valve 346 may be positioned along piping 342 or piping 344 to control a flow rate of the chilled fluid through cooling coil 334. In some embodiments, cooling coil 334 includes multiple stages of cooling coils that can be independently activated and deactivated (e.g., by AHU controller 330, by BAS controller 366, etc.) to modulate an amount of cooling applied to supply air 310.

Heating coil 336 may receive a heated fluid from waterside system 200 (e.g., from hot water loop 214) via piping 348 and may return the heated fluid to waterside system 200 via piping 350. Valve 352 may be positioned along piping 348 or piping 350 to control a flow rate of the heated fluid through heating coil 336. In some embodiments, heating coil 336 includes multiple stages of heating coils that can be independently activated and deactivated (e.g., by AHU controller 330, by BAS controller 366, etc.) to modulate an amount of heating applied to supply air 310.

Each of valves 346 and 352 may be controlled by an actuator. For example, valve 346 may be controlled by actuator 354 and valve 352 may be controlled by actuator 356. Actuators 354-356 may communicate with AHU controller 330 via communications links 358-360. Actuators 354-356 may receive control signals from AHU controller 330 and may provide feedback signals to controller 330. In some embodiments, AHU controller 330 receives a measurement of the supply air temperature from a temperature sensor 362 positioned in supply air duct 312 (e.g., downstream of cooling coil 334 and/or heating coil 336). AHU controller 330 may also receive a measurement of the temperature of building zone 306 from a temperature sensor 364 located in building zone 306.

In some embodiments, AHU controller 330 operates valves 346 and 352 via actuators 354-356 to modulate an amount of heating or cooling provided to supply air 310 (e.g., to achieve a setpoint temperature for supply air 310 or to maintain the temperature of supply air 310 within a setpoint temperature range). The positions of valves 346 and 352 affect the amount of heating or cooling provided to supply air 310 by cooling coil 334 or heating coil 336 and may correlate with the amount of energy consumed to achieve a desired supply air temperature. AHU 330 may control the temperature of supply air 310 and/or building zone 306 by activating or deactivating coils 334-336, adjusting a speed of fan 338, or a combination of both.

Still referring to FIG. 3, airside system 300 is shown to include a building automation system (BAS) controller 366 and a client device 368. BAS controller 366 may include one or more computer systems (e.g., servers, supervisory controllers, subsystem controllers, etc.) that serve as system level controllers, application or data servers, head nodes, or master controllers for airside system 300, waterside system 200, HVAC system 100, and/or other controllable systems that serve building 10. BAS controller 366 may communicate with multiple downstream building systems or subsystems (e.g., HVAC system 100, a security system, a lighting system, waterside system 200, etc.) via a communications link 370 according to like or disparate protocols (e.g., LON, BACnet, etc.). In various embodiments, AHU controller 330 and BAS controller 366 may be separate (as shown in FIG. 3) or integrated. In an integrated implementation, AHU controller 330 may be a software module configured for execution by a processor of BAS controller 366.

In some embodiments, AHU controller 330 receives information from BAS controller 366 (e.g., commands, setpoints, operating boundaries, etc.) and provides information to BAS controller 366 (e.g., temperature measurements, valve or actuator positions, operating statuses, diagnostics, etc.). For example, AHU controller 330 may provide BAS controller 366 with temperature measurements from temperature sensors 362-364, equipment on/off states, equipment operating capacities, and/or any other information that can be used by BAS controller 366 to monitor or control a variable state or condition within building zone 306.

Client device 368 may include one or more human-machine interfaces or client interfaces (e.g., graphical user interfaces, reporting interfaces, text-based computer interfaces, client-facing web services, web servers that provide pages to web clients, etc.) for controlling, viewing, or otherwise interacting with HVAC system 100, its subsystems, and/or devices. Client device 368 may be a computer workstation, a client terminal, a remote or local interface, or any other type of user interface device. Client device 368 may be a stationary terminal or a mobile device. For example, client device 368 may be a desktop computer, a computer server with a user interface, a laptop computer, a tablet, a smartphone, a PDA, or any other type of mobile or non-mobile device. Client device 368 may communicate with BAS controller 366 and/or AHU controller 330 via communications link 372.

Referring now to FIG. 4, a block diagram of a building automation system (BAS) 400 is shown, according to an exemplary embodiment. BAS 400 may be implemented in building 10 to automatically monitor and control various building functions. BAS 400 is shown to include BAS controller 366 and a plurality of building subsystems 428. Building subsystems 428 are shown to include a building electrical subsystem 434, an information communication technology (ICT) subsystem 436, a security subsystem 438, a HVAC subsystem 440, a lighting subsystem 442, a lift/escalators subsystem 432, and a fire safety subsystem 430. In various embodiments, building subsystems 428 can include fewer, additional, or alternative subsystems. For example, building subsystems 428 may also or alternatively include a refrigeration subsystem, an advertising or signage subsystem, a cooking subsystem, a vending subsystem, a printer or copy service subsystem, or any other type of building subsystem that uses controllable equipment and/or sensors to monitor or control building 10. In some embodiments, building subsystems 428 include waterside system 200 and/or airside system 300, as described with reference to FIGS. 2-3.

Each of building subsystems 428 may include any number of devices, controllers, and connections for completing its individual functions and control activities. HVAC subsystem 440 may include many of the same components as HVAC system 100, as described with reference to FIGS. 1-3. For example, HVAC subsystem 440 may include a chiller, a boiler, any number of air handling units, economizers, field controllers, supervisory controllers, actuators, temperature sensors, and other devices for controlling the temperature, humidity, airflow, or other variable conditions within building 10. Lighting subsystem 442 may include any number of light fixtures, ballasts, lighting sensors, dimmers, or other devices configured to controllably adjust the amount of light provided to a building space. Security subsystem 438 may include occupancy sensors, video surveillance cameras, digital video recorders, video processing servers, intrusion detection devices, access control devices and servers, or other security-related devices.

Still referring to FIG. 4, BAS controller 366 is shown to include a communications interface 407 and a BAS interface 409. Interface 407 may facilitate communications between BAS controller 366 and external applications (e.g., monitoring and reporting applications 422, enterprise control applications 426, remote systems and applications 444, applications residing on client devices 448, etc.) for allowing user control, monitoring, and adjustment to BAS controller 366 and/or subsystems 428. Interface 407 may also facilitate communications between BAS controller 366 and client devices 448. BAS interface 409 may facilitate communications between BAS controller 366 and building subsystems 428 (e.g., HVAC, lighting security, lifts, power distribution, business, etc.). In some embodiments, interface 407 and interface 409 can be implemented as one interface. In some embodiments, the communications interface 407 is an external communication interface while the BAS interface 409 is implemented as an internal communication interface.

Interfaces 407, 409 can be or include wired or wireless communications interfaces (e.g., jacks, antennas, transmitters, receivers, transceivers, wire terminals, etc.) for conducting data communications with building subsystems 428 or other external systems or devices. In various embodiments, communications via interfaces 407, 409 may be direct (e.g., local wired or wireless communications) or via a communications network 446 (e.g., a WAN, the Internet, a cellular network, etc.). For example, interfaces 407, 409 can include an Ethernet card and port for sending and receiving data via an Ethernet-based communications link or network. In another example, interfaces 407, 409 can include a Wi-Fi transceiver for communicating via a wireless communications network. In another example, one or both of interfaces 407, 409 may include cellular or mobile phone communications transceivers. In one embodiment, communications interface 407 is a power line communications interface and BAS interface 409 is an Ethernet interface. In other embodiments, both communications interface 407 and BAS interface 409 are Ethernet interfaces or are the same Ethernet interface. In some embodiments, the communications via the two interfaces can use Internet Protocol (IP) or other protocols.

Still referring to FIG. 4, BAS controller 366 is shown to include a processing circuit 404 including a processor 406 and memory 408. Processing circuit 404 may be communicably connected to BAS interface 409 and/or communications interface 407 such that processing circuit 404 and the various components thereof can send and receive data via interfaces 407, 409. Processor 406 can be implemented as a general purpose processor, an application specific integrated circuit (ASIC), one or more field programmable gate arrays (FPGAs), a group of processing components, or other suitable electronic processing components.

Memory 408 (e.g., memory, memory unit, storage device, etc.) may include one or more devices (e.g., RAM, ROM, Flash memory, hard disk storage, etc.) for storing data and/or computer code for completing or facilitating the various processes, layers and modules described in the present application. Memory 408 may be or include volatile memory or non-volatile memory. Memory 408 may include database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described in the present application. According to an exemplary embodiment, memory 408 is communicably connected to processor 406 via processing circuit 404 and includes computer code for executing (e.g., by processing circuit 404 and/or processor 406) one or more processes described herein.

In some embodiments, BAS controller 366 is implemented within a single computer (e.g., one server, one housing, etc.). In various other embodiments BAS controller 366 may be distributed across multiple servers or computers (e.g., that can exist in distributed locations). Further, while FIG. 4 shows applications 422 and 426 as existing outside of BAS controller 366, in some embodiments, applications 422 and 426 may be hosted within BAS controller 366 (e.g., within memory 408).

Still referring to FIG. 4, memory 408 is shown to include an enterprise integration layer 410, an automated measurement and validation (AM&V) layer 412, a demand response (DR) layer 414, a fault detection and diagnostics (FDD) layer 416, an integrated control layer 418, and a building subsystem integration layer 420. Layers 410-420 may be configured to receive inputs from building subsystems 428 and other data sources, determine optimal control actions for building subsystems 428 based on the inputs, generate control signals based on the optimal control actions, and provide the generated control signals to building subsystems 428. The following paragraphs describe some of the general functions performed by each of layers 410-420 in BAS 400.

Enterprise integration layer 410 may be configured to serve clients or local applications with information and services to support a variety of enterprise-level applications. For example, enterprise control applications 426 may be configured to provide subsystem-spanning control to a graphical user interface (GUI) or to any number of enterprise-level business applications (e.g., accounting systems, user identification systems, etc.). Enterprise control applications 426 may also or alternatively be configured to provide configuration GUIs for configuring BAS controller 366. In yet other embodiments, enterprise control applications 426 can work with layers 410-420 to optimize building performance (e.g., efficiency, energy use, comfort, or safety) based on inputs received at interface 407 and/or BAS interface 409.

Building subsystem integration layer 420 may be configured to manage communications between BAS controller 366 and building subsystems 428. For example, building subsystem integration layer 420 may receive sensor data and input signals from building subsystems 428 and provide output data and control signals to building subsystems 428. Building subsystem integration layer 420 may also be configured to manage communications between building subsystems 428. Building subsystem integration layer 420 translate communications (e.g., sensor data, input signals, output signals, etc.) across a plurality of multi-vendor/multi-protocol systems.

Demand response layer 414 may be configured to optimize resource usage (e.g., electricity use, natural gas use, water use, etc.) and/or the monetary cost of such resource usage in response to satisfy the demand of building 10. The optimization may be based on time-of-use prices, curtailment signals, energy availability, or other data received from utility providers, distributed energy generation systems 424, from energy storage 427 (e.g., hot TES 242, cold TES 244, etc.), or from other sources. Demand response layer 414 may receive inputs from other layers of BAS controller 366 (e.g., building subsystem integration layer 420, integrated control layer 418, etc.). The inputs received from other layers may include environmental or sensor inputs such as temperature, carbon dioxide levels, relative humidity levels, air quality sensor outputs, occupancy sensor outputs, room schedules, and the like. The inputs may also include inputs such as electrical use (e.g., expressed in kWh), thermal load measurements, pricing information, projected pricing, smoothed pricing, curtailment signals from utilities, and the like.

According to an exemplary embodiment, demand response layer 414 includes control logic for responding to the data and signals it receives. These responses can include communicating with the control algorithms in integrated control layer 418, changing control strategies, changing setpoints, or activating/deactivating building equipment or subsystems in a controlled manner. Demand response layer 414 may also include control logic configured to determine when to utilize stored energy. For example, demand response layer 414 may determine to begin using energy from energy storage 427 just prior to the beginning of a peak use hour.

In some embodiments, demand response layer 414 includes a control module configured to actively initiate control actions (e.g., automatically changing setpoints) which minimize energy costs based on one or more inputs representative of or based on demand (e.g., price, a curtailment signal, a demand level, etc.). In some embodiments, demand response layer 414 uses equipment models to determine an optimal set of control actions. The equipment models may include, for example, thermodynamic models describing the inputs, outputs, and/or functions performed by various sets of building equipment. Equipment models may represent collections of building equipment (e.g., subplants, chiller arrays, etc.) or individual devices (e.g., individual chillers, heaters, pumps, etc.).

Demand response layer 414 may further include or draw upon one or more demand response policy definitions (e.g., databases, XML files, etc.). The policy definitions may be edited or adjusted by a user (e.g., via a graphical user interface) so that the control actions initiated in response to demand inputs may be tailored for the user's application, desired comfort level, particular building equipment, or based on other concerns. For example, the demand response policy definitions can specify which equipment may be turned on or off in response to particular demand inputs, how long a system or piece of equipment should be turned off, what setpoints can be changed, what the allowable set point adjustment range is, how long to hold a high demand setpoint before returning to a normally scheduled setpoint, how close to approach capacity limits, which equipment modes to utilize, the energy transfer rates (e.g., the maximum rate, an alarm rate, other rate boundary information, etc.) into and out of energy storage devices (e.g., thermal storage tanks, battery banks, etc.), and when to dispatch on-site generation of energy (e.g., via fuel cells, a motor generator set, etc.).

Integrated control layer 418 may be configured to use the data input or output of building subsystem integration layer 420 and/or demand response later 414 to make control decisions. Due to the subsystem integration provided by building subsystem integration layer 420, integrated control layer 418 can integrate control activities of the subsystems 428 such that the subsystems 428 behave as a single integrated supersystem. In an exemplary embodiment, integrated control layer 418 includes control logic that uses inputs and outputs from a plurality of building subsystems to provide greater comfort and energy savings relative to the comfort and energy savings that separate subsystems could provide alone. For example, integrated control layer 418 may be configured to use an input from a first subsystem to make an energy-saving control decision for a second subsystem. Results of these decisions can be communicated back to building subsystem integration layer 420.

Integrated control layer 418 is shown to be logically below demand response layer 414. Integrated control layer 418 may be configured to enhance the effectiveness of demand response layer 414 by enabling building subsystems 428 and their respective control loops to be controlled in coordination with demand response layer 414. This configuration may advantageously reduce disruptive demand response behavior relative to conventional systems. For example, integrated control layer 418 may be configured to assure that a demand response-driven upward adjustment to the setpoint for chilled water temperature (or another component that directly or indirectly affects temperature) does not result in an increase in fan energy (or other energy used to cool a space) that would result in greater total building energy use than was saved at the chiller.

Integrated control layer 418 may be configured to provide feedback to demand response layer 414 so that demand response layer 414 checks that constraints (e.g., temperature, lighting levels, etc.) are properly maintained even while demanded load shedding is in progress. The constraints may also include setpoint or sensed boundaries relating to safety, equipment operating limits and performance, comfort, fire codes, electrical codes, energy codes, and the like. Integrated control layer 418 is also logically below fault detection and diagnostics layer 416 and automated measurement and validation layer 412. Integrated control layer 418 may be configured to provide calculated inputs (e.g., aggregations) to these higher levels based on outputs from more than one building subsystem.

Automated measurement and validation (AM&V) layer 412 may be configured to verify that control strategies commanded by integrated control layer 418 or demand response layer 414 are working properly (e.g., using data aggregated by AM&V layer 412, integrated control layer 418, building subsystem integration layer 420, FDD layer 416, or otherwise). The calculations made by AM&V layer 412 may be based on building system energy models and/or equipment models for individual BAS devices or subsystems. For example, AM&V layer 412 may compare a model-predicted output with an actual output from building subsystems 428 to determine an accuracy of the model.

Fault detection and diagnostics (FDD) layer 416 may be configured to provide on-going fault detection for building subsystems 428, building subsystem devices (i.e., building equipment), and control algorithms used by demand response layer 414 and integrated control layer 418. FDD layer 416 may receive data inputs from integrated control layer 418, directly from one or more building subsystems or devices, or from another data source. FDD layer 416 may automatically diagnose and respond to detected faults. The responses to detected or diagnosed faults may include providing an alert message to a user, a maintenance scheduling system, or a control algorithm configured to attempt to repair the fault or to work-around the fault.

FDD layer 416 may be configured to output a specific identification of the faulty component or cause of the fault (e.g., loose damper linkage) using detailed subsystem inputs available at building subsystem integration layer 420. In other exemplary embodiments, FDD layer 416 is configured to provide “fault” events to integrated control layer 418 which executes control strategies and policies in response to the received fault events. According to an exemplary embodiment, FDD layer 416 (or a policy executed by an integrated control engine or business rules engine) may shut-down systems or direct control activities around faulty devices or systems to reduce energy waste, extend equipment life, or assure proper control response.

FDD layer 416 may be configured to store or access a variety of different system data stores (or data points for live data). FDD layer 416 may use some content of the data stores to identify faults at the equipment level (e.g., specific chiller, specific AHU, specific terminal unit, etc.) and other content to identify faults at component or subsystem levels. For example, building subsystems 428 may generate temporal (i.e., time-series) data indicating the performance of BAS 400 and the various components thereof. The data generated by building subsystems 428 may include measured or calculated values that exhibit statistical characteristics and provide information about how the corresponding system or process (e.g., a temperature control process, a flow control process, etc.) is performing in terms of error from its setpoint. These processes can be examined by FDD layer 416 to expose when the system begins to degrade in performance and alert a user to repair the fault before it becomes more severe.

Interconnection of OT and IT Networks within a Building Automation System

Referring now to FIG. 5, a block diagram of a system 500 used to interconnect an OT and IT network is shown, according to an exemplary embodiment. System 500 can be implemented in building 10 to interconnect the operational technology (OT) and information technology (IT) networks of the building. System 500 is shown to include interconnecting network tool 502, client devices 520, building automation system (BAS) devices 522, OT network 516, IT network 514, and user 518.

System 500 is shown to include an operation technology (OT) network 516. The OT network 516 may be used to monitor and facilitate communication between physical equipment and processes within the BAS. The OT network 516 may be installed in segments, for example corresponding to the physical layout of the building. Within each segment, packets of data may be handled using the protocols of layer 2 in the Open System Interconnection (OSI) model. For example, packets of data may be handled via Ethernet, fiber channels, media access control (MAC) addresses, and/or switches. Communication between segments may be handled using the protocols of layer 3 in the OSI model. For instance, communication between segments may be handled using internet protocol version 4 (IPv4), internet protocol version 6 (IPv6), internet control message protocol (ICMP), multiprotocol label switching (MPLS), address resolution protocol (ARP), routing, and/or IP addresses. Traffic within the OT network 516 may be controlled using static routing statements. The routing statements can direct packets of data from one segment to all other segments.

System 500 is shown to include client device 520. Client device 520 can include one or more human-machine interfaces or client interfaces (e.g., graphical user interfaces, reporting interfaces, text-based computer interfaces, client-facing web services, web servers that provide pages to web clients, etc.) for controlling, viewing, or otherwise interacting with system 500, its subsystems, and/or devices. Client device 520 can be a computer workstation, a client terminal, a remote or local interface, or any other type of user interface device. Client device 520 can be a stationary terminal or a mobile device. For example, client device 520 can be a desktop computer, a computer server with a user interface, a laptop computer, a tablet, a smartphone, a PDA, or any other type of mobile or non-mobile device. Client device 520 can communicate with interconnecting network tool 502 via communications interface 512. A user 518 may operate client device 520.

System 500 is shown to include a building automation system (BAS) device 522. System 500 may include one or more BAS device 522s.

System 500 is shown to include a user 518. User 518 may be a BAS site manager, a member of the technology team, and/or anyone responsible for the migration of networks. User 518 can provide system inputs and receive system outputs via client device 520 and communications interface 512. User 518 may manually update a BAS device 522. User 518 may also push switch configuration files out to the network switches of the OT network 516 and/or IT network 514.

Still referring to FIG. 5, interconnecting network tool 502 is shown to include a communications interface 512. Interface 512 can facilitate communications between interconnecting network tool 502 and networks (e.g., OT network 516, IT network 514, etc.) for interconnecting the networks within building 10. Interface 512 can also facilitate communications between interconnecting network tool 512 and external devices (e.g., client devices 520, BAS devices 522, etc.) to provide user interfaces to be displayed.

Communications interface 512 can be or include wired or wireless communications interfaces (e.g., jacks, antennas, transmitters, receivers, transceivers, wire terminals, etc.) for conducting data communications with networks or other external systems or devices. In various embodiments, communications via interface 512 can be direct (e.g., local wired or wireless communications) or via a communications network 446 (e.g., a WAN, the Internet, a cellular network, etc.). For example, interface 512 can include an Ethernet card and port for sending and receiving data via an Ethernet-based communications link or network. In another example, interface 512 can include a Wi-Fi transceiver for communicating via a wireless communications network. In another example, interface 512 can include cellular or mobile phone communications transceivers. Communications interface 512 may include one or more interfaces to enable interconnecting network tool 502 to access a network such as a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or the Internet through a variety of wired and/or wireless or cellular connections.

Still referring to FIG. 5, interconnecting network tool 502 is shown to include a processing circuit 504 including a processor 506 and memory 508. Processing circuit 504 can be communicably connected to communications interface 512 such that processing circuit 504 and the various components thereof can send and receive data via interface 512. Processor 506 can be implemented as a general purpose processor, an application specific integrated circuit (ASIC), one or more field programmable gate arrays (FPGAs), a group of processing components, or other suitable electronic processing components.

Memory 508 (e.g., memory, memory unit, storage device, etc.) can include one or more devices (e.g., RAM, ROM, Flash memory, hard disk storage, etc.) for storing data and/or computer code for completing or facilitating the various processes, layers and modules described in the present application. Memory 508 can be or include volatile memory or non-volatile memory. Memory 508 can include database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described in the present application. According to some embodiments, memory 508 is communicably connected to processor 506 via processing circuit 504 and includes computer code for executing (e.g., by processing circuit 504 and/or processor 506) one or more processes described herein.

Still referring to FIG. 5, memory 510 is shown to include a configuration wizard 510. Configuration wizard 510 may configured to perform process 600, as described in reference in FIG. 6.

Referring now to FIGS. 6A-6B, a process 600 is shown for interconnecting an IT network 514 and OT network 516 within the building of FIG. 1, according to an exemplary embodiment. The interconnecting network tool 502 can be configured to perform the process 600. More specifically, the configuration wizard 510 can be configured to perform the process 600.

Process 600 is shown to include receiving inputs and switch configurations of a network to be integrated into an IT network (602). The IT network 514 may already be installed at the building site. The network being integrated with the IT network 514 may be the OT network 516 described in connection to FIG. 5. Via the communications interface 512 the configuration wizard 510 may receive the original inputs and original switch configurations of OT network 516. The received network information may allow the configuration wizard 510 to determine which network is to be integrated in to the IT network 514.

Process 600 is shown to include scanning the design of the network and extracting the IP address and virtual local area of network (VLAN) of each device of the network (604). Configuration wizard 510 may be configured to examine the network design of OT network 516. From its examination, the configuration wizard 510 may be able to determine a list of devices that are on that network, along with their IP addresses and VLANs. Each device of the network may be a BAS device 522 described in connection to FIG. 5.

Process 600 is shown to include receiving changes that are required by the IT network for the integration of networks (606). Via the communications interface 512 the configuration wizard 510 may receive any changes required by the IT network 514 to allow for successful integration of the networks. The changes may include IP addresses and VLANs for equipment that will reside in the address space of the IT network 514 after the migration. The changes may also include the default gateway address for the BAS devices that need to access IT services. For example, a BAS device 522 may require internet connection and therefore would need access to the IT services.

Process 600 is shown to include determining if conflicts exist between the configuration of the network and a configuration required to connect the network and the IT network (608). Configuration wizard 510 may determine if there are any conflicts between the current configuration of the OT network 516 and the configuration required to interconnect the OT network 516 and the IT network 514. For example, conflicts may include overlapping or conflicting subnets, VLANS, duplicate addresses, etc. If any conflicts are detected, process 600 may proceed with operation 610. Otherwise, process 600 may proceed with operation 612 to continue with the interconnecting of networks.

Upon determination of existing conflicts, process 600 is shown to include displaying the conflicts and exiting the process (610). Configuration wizard 510 may display a user interface demonstrating the existing conflicts on a client device 520 via communications interface 512. A user 518 may view the user interface on client device 520. Once the conflicts are displayed, configuration wizard 510 may terminate process 600. The user 518 may review the conflicts and make the necessary changes to the networks and/or devices. Once the user 518 believes the conflicts are resolved, the user 518 may run the configuration wizard 510 to start process 600 again.

Upon determination of no existing conflicts, process 600 is shown to include updating the network configuration of the impacted devices of the network (612). As necessary, the configuration wizard 510 may update the network configuration of the impacted devices of OT network 516 and/or IT network 514. The list of impacted devices may come from operation 604 and/or operation 606. Impacted devices may include a single BAS device 522 or a plurality of BAS device 522s. Updating the network configuration may include specifying the correct IP addresses and route settings, setting up a network connection to enable communication, modifying existing addresses, etc.

Process 600 is shown to include updating routing tables of the network switches to route the required IP traffic between the network and the IT network (614). Configuration wizard 510 may update the routing tables of the network switches in order to route the required IP traffic between the OT network 516 and the IT network 514 as well as update access control lists based on IP addresses that may be applied to switch interfaces. In some embodiments, the traffic of the OT network 516 that does not need to be exposed to the IT network 514 remains within the OT network 516.

Process 600 is shown to include generating new switch configurations (616). Configuration wizard 510 may generate new network switch configurations to update the route of traffic to and from the OT network 516 and IT network 514.

Process 600 is shown to include writing out the modified switch configurations, list of impacted BAS devices, and any required changes to be manually applied to the BAS devices (618). Configuration wizard 510 may write out the modified switch configurations to be pushed out in operation 624. Configuration wizard 510 may also write out the list of impacted devices (BAS devices that are not switches) to be manually updated in operation 622. In addition, configuration wizard 510 may write out the required changes to be manually applied to the devices in operation 620. Required changes may include updating a device's IP address to their new IP address in the IT network 514, updating a device's default gateway to their new default gateway, etc.

Process 600 is shown to include displaying a prompt to review the changes for network migration (620). Configuration wizard 510 may display a user interface on a client device 520 via the communications interface 512 displaying the changes for the network migration, along with a prompt for someone responsible for the migration to review the changes. A user 518 may view the user interface on the client device 520 to review to the changes for the network migration. If the user 518 agrees with the suggested changes, process 600 may proceed with operation 622. In the case that the user 518 does not agree with the suggested changes for various reasons, the user 518 may elect to not continue with process 600.

Process 600 is shown to include displaying a prompt to manually update the impacted BAS devices as specified (622). Configuration wizard 510 may display a user interface on a client device 520 via the communications interface 512 prompting to manually update the impacted BAS devices as specified. A user 518 may view the user interface on the client device 520 in order to assess the impacted BAS devices and how they need to be updated. The list of impacted BAS devices may be produced in operation 618. The user 518 may manually update the BAS devices listed accordingly. If the user 518 does not manually update the BAS devices as the configuration wizard 510 specifies, process 600 may not be able to proceed with operation 624 and the network migration may not be completed.

Process 600 is shown to include displaying a prompt to push the updated configuration files out to the network switches (624). Configuration wizard 510 may display a user interface on a client device 520 via the communications interface 512 prompting to push the updated configuration files out to the network switches. A user 518 may view the user interface on the client device 520 and determine that they need to push the updated configuration files out to the network switches. The user 518 may push the updated configuration files out to the network switches. Once all of the network switches are reloaded, the network migration is complete. However, if the user 518 decides not to push the updated configuration files out to the network switches or if all of the network switches are not reloaded, the network migration will fail and will not be complete.

Referring now to FIG. 7, a schematic diagram of an isolated OT network to be used by the interconnecting network tool of FIG. 5 is shown, according to an exemplary embodiment. The isolated OT network shown may be the OT network 516 and the IT network shown may be the IT network 514, as described in reference to FIG. 5. The schematic diagram demonstrates how the OT network is isolated from the IT network prior to using the interconnecting network tool 502, as described in reference to FIG.

The OT network may be installed in segments and the plurality of OT VLAN/subnets in FIG. 7 demonstrates these segments. A single OT VLAN/subnet may be designated to be the main OT VLAN/subnet of the OT network. This subnet can contain an OT aggregation switch, an OT site director, and all OT access switches for the OT network. All OT access switches and the OT site director have may have static IP addresses from the OT IP address space. OT access switches can access the network via communication lines, such as trunks. Within each OT VLAN/subnet can be field equipment controllers (FEC) and a network automation engine (NAE). In certain embodiments, all FECs and their associated NAE may share the same OT VLAN/subnet. Devices within the OT VLAN/subnet may communicate throughout the network in a variety of ways. A single FEC may be connected directly to the OT access switch. In some embodiments, a group of FECs may be a part of a ‘daisy chain’ where multiple devices are connected together in a sequence. In certain embodiments, a group of FECs may participate in a ring managed by a layer 2 protocol such as a media redundancy protocol (MRP). All FECs may have dynamic IP addresses from the OT IP address space provided by the associated OT access switch. With the isolated OT network, all devices within the network are directly reachable from and to each other within the OT network.

Referring now to FIG. 8, a schematic diagram illustrating an OT network interconnected to an IT network is shown, according to an exemplary embodiment. The isolated OT network shown may be the OT network 516 and the IT network shown may be the IT network 514, as described in reference to FIG. 5. The OT network and the IT network may be interconnected by a process, for example process 600 described in reference to FIGS. 6A-6B. During a process (such as process 600), the OT switches may be updated with the switch configuration files generated by the interconnecting network tool 502 and the configuration of the OT site director may be manually updated as instructed by the interconnecting network tool 502. Upon interconnecting the OT network and the IT network, all OT access switches and the OT site director may be moved to an IT VLAN/subnet. The OT access switches and the OT site director may have static IP addresses from the IT IP address space. In addition, the OT aggregation switch may be configured with a routed port in the IT network through which the OT network traffic to and from the IT network is routed. The routing table of the OT aggregation switch may also be updated to route traffic from the OT site director to either the NAEs of each OT VLAN/subnet or the IT network, depending on the destination IP address. OT switches and the OT site director may be visible to and accessible from the IT network, however NAEs and FECs may not be visible to or accessible from the IT network.

Automated Design and Configuration of an IP Network

FIG. 9 is a block diagram illustrating a system 900 for automatically configuring an IP network, according to an exemplary embodiment. Referring to FIG. 9, system 900 is shown to include IP network design and configuration tool 905, building automation system (BAS) 915, IP network (OT network) 920, IT network 925, user 930, and client device 935. In some embodiments, system 900 can be implemented in building 10 to configure the BAS system 915 into an IP based system. In other embodiments, some components of system 900 (e.g., IP network design and configuration tool 905, user 930, and/or client device 935) can be in one or more locations remote from building 10 and can communicate with other components of system 900 via one or more communication networks.

The system 900 is shown to include an IP network design and configuration tool 905 which can implement the operations as described herein below to configure the BAS system 915 into an IP based system. The IP network design and configuration tool 905 is described in more detail in relation to FIG. 10. In some embodiments, the IP network design and configuration tool 905 can include, among other components for example as described in to FIG. 10, a communication interface 910 which allows the IP network design and configuration tool 905 to communicate with other devices within and outside of the system 900.

The system 900 is shown to include a building automation system (BAS) 915. BAS 915 can be the building automation system as described in relation to FIGS. 1-4. As described herein below, the IP network design and configuration tool 905 can configure the BAS 915 into an IP based system to allow devices in the BAS 915 to communicate with other devices inside and outside of BAS 915 using the Internet Protocol (IP). In some embodiments, the IP network (OT network) 920 can be the OT network 516 in FIG. 5.

The system 900 is shown to include client device 935. Client device 935 can be similar to the client device 520 as described in relation to FIG. 5. Client device 935 can communicate with the IP network design and configuration tool 905 via communications interface 910. In some embodiments, a user 930 may operate the client device 935. User 935 may be a BAS site manager, a field engineer/technician, a member of the technology team, and/or anyone who is to configure IP networks. User 930 can provide system inputs and receive system outputs via client device 935 and communications interface 910. User 930 may also push switch configuration files out to the network switches of the IP network (OT network) 920 and/or IT network 925. IT network 925 can be customer's IT network at building 10, in some embodiments.

FIG. 10 is a block diagram illustrating an example device 1000 for automatically configuring an IP network, according to an exemplary embodiment. The IP network design and configuration device 1000 can be the IP network design and configuration tool 905 as described in FIG. 9. In some embodiments, device 1000 can include a processing circuit 1010 and a communications interface 1065, among other components. The processing circuit 1010 is shown to include a processor 1015 and a memory 1020. In some embodiments, the processor 1015 can be implemented as a special purpose processor, a general purpose processor, an application specific integrated circuit (ASIC), one or more field programmable gate arrays (FPGAs), a group of processing components, or other suitable electronic processing components. The processor 1015 may be configured to execute computer code or computer-executable instructions stored in memory or received from other non-transitory computer readable media (e.g., CDROM, network storage, a remote server, etc.).

Memory 1020 (e.g., memory, memory unit, storage device, etc.) can include one or more devices (e.g., RAM, ROM, Flash memory, hard disk storage, etc.) for storing data and/or computer code for completing or facilitating the various processes, layers and modules described in the present application. Memory 1020 can be or include volatile memory or non-volatile memory. Memory 1020 can include database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described in the present application. Memory 1020 may be communicably connected to the processor via the processing circuit and may include computer code for executing (e.g., by the processor) one or more processes described herein.

In some embodiments, the memory 1020 can include at least an input processing module 1025, a device identification module 1030, a subnet and switch allocation module 1035, a subnet consolidation module 1040, an IP planning module 1045, a configuration file generation module 1050, an installation document generation module 1055, and an external media management module 1060. In other embodiments, more, less, or different modules or components can be stored in memory 1020. In some embodiments, the modules 1025-1060 can be implemented in one apparatus, such as the device 1000. In other embodiments, each of the modules 1025-1060 can be implemented in different and separate apparatuses and/or executed by different and separate processors, or a combination thereof. In some embodiments, modules 1025-1060 stored in a non-transitory computer readable medium (e.g., memory 1020) can be executed by the processor 1015 to perform operations as described herein. In some embodiments, each of the modules 1025-1060 or a combination of some of the modules 1025-1060 can be implemented as hardware circuits.

The communications interface 1065 (or communications interface 910 in FIG. 9) allows the device 1000 or the tool 905 to communicate with other devices within and outside of the system 900 in FIG. 9. In some embodiments, the communications interface 1065 includes wired or wireless interfaces (e.g., jacks, antennas, transmitters, receivers, transceivers, wire terminals, etc.) for conducting data communications with various systems, devices, or networks. For example, the communications interface 1065 may include an Ethernet card and port for sending and receiving data via an Ethernet-based communications network and/or a Wi-Fi transceiver for communicating via a wireless communications network.

FIG. 11 is a block diagram illustrating an example high level IP based BAS system 1100 configured using the IP network design and configuration tool, according to an exemplary embodiment. It should be understood that the example IP based BAS system in FIG. 11 is shown in a high level and simplified fashion for purposes of illustration and facilitating understanding, and should not be regarded as limiting.

The system 1100 is shown to include a plurality of access switches 1120, 1125. Each of the access switches 1120, 1125 can connect a plurality of other devices via a plurality of ports of the access switch. For example, as illustrated in FIG. 11, the access switch 1120 can connect one or more network controllers 1130, one or more BAS controllers 1140, and/or one or more BAS devices 1145 via a plurality of ports of the access switch 1120. Similarly, the access switch 1125 can connect one or more network controllers 1135, one or more BAS controllers 1150, and/or one or more BAS devices 1155, 1160 via a plurality of ports of the access switch 1125. In some embodiments, one or more of the BAS controllers and/or BAS devices may not connect to the access switch directly due to, for example, the BAS controllers and/or BAS devices do not have the hardware capability to connect to a switch port. In those embodiments, the BAS controllers and/or BAS devices may connect to a network controller which connects to the access switch. In some embodiments, access switches can communicate with each other. The network controllers 1130, 1135 can be Network Automation Engines (NAEs) or other network controllers, in some embodiments. The BAS controllers 1140, 1150 can be any of the controllers as described in relation to FIGS. 1-4. The BAS devices 1145, 1155, 1160 can be any of devices in the building subsystems, such as HVAC devices, lighting devices, fire safety devices, etc., as described in relation to FIGS. 1-4.

In some embodiments, the system 1100 may include at least one aggregation switch, depending on the IP network architecture. For example, if it is determined that a separate aggregation switch is included in the IP network architecture for aggregation of the access switches and routing between the access switches, the system 1100 may include the aggregation switch. As illustrated in FIG. 11, an aggregation switch 1110 can connect the plurality of access switches 1120, 1125. In some embodiments, the system 1100 may not include an aggregation switch, and the functionality of the aggregation switch may be configured on an access switch, just as in some embodiments that the access switch functionality may be configured on an aggregation switch. While FIG. 11 shows example components of system 1100, in other embodiments, system 1100 can include additional, different, fewer, and/or differently-arranged components than those depicted in FIG. 11. For example, while FIG. 11 shows two access switches, system 1100 can have any number of access switches. The configuration and arrangement of each switch, controller, and device, etc. as shown in FIG. 11 are for illustrative purposes only and are not limiting.

Referring now to FIGS. 9-11 together, in some embodiments, the IP network design and configuration device 1000 or tool 905 can receive inputs comprising information specific to a building automation system (BAS) and information specific to an IP network. For example, the input processing module 1025 executed by the processor 1015 of the device 1000 can be configured to receive or obtain inputs from one or more storage devices or databases, or another device within or outside of the system 900.

In some embodiments, the inputs can include information specific to the BAS. The information specific to the BAS can include, for example, information of the BAS devices that are to be connected via the BAS IP network, the relationships between the devices (e.g., which controllers will be supervised by a network controller, e.g., NAE), the required behavior of the BAS system (e.g., how the system should report errors, the physical location of the devices/controllers (e.g., the floor of the building on which they will be installed)), and attributes of the BAS system (e.g., what values should be used for the BACnet port numbers). In some embodiments, for information specific to the BAS, high level information or specific details of devices (e.g., a list of individual devices, a list of groups of devices) can be provided. High level information or inputs, for example, can include total number of devices to be connected and the models (or other attributes) of the network controllers (e.g., NAEs) to be used to supervise those devices. Specific details of each device, for instance, can include information of the specific network controller (e.g., NAE) that can supervise the device, the general installed location of the device at the job site, etc.

In some embodiments, the inputs can include information specific to the IP network. The information specific to the IP network can include information specifying the relationship between the BAS IP network and the customer's IT network (e.g., whether the BAS IP network is a separate network from the IT network; if not, the level of integration with the customer's IT network) and how the devices will be connected to the IP network (e.g., via star/home run, daisy chain, or redundant ring (the information specific to the connected devices can include protocol information such as BACnet and Media Redundancy Protocol (MRP) ring)). For example, if the BAS IP network is to be integrated with the customer's IT network, at least a limited amount of information regarding how the systems are integrated are to be provided as inputs. In some embodiments, for information specific to the IP network, high level information or specific details of devices (e.g., a list of individual devices, a list of groups of devices) can be provided. High level information or inputs, for example, can include how the BAS devices are to be connected to the BAS IP network, such as the total number of BAS devices for each connection method, the average length of the daisy chains, etc. Specific details of each device, for instance, can include information of how the device will be connected to the BAS IP network, the specific daisy chain or redundant ring that the device will be connected to, if applicable, etc.

In some embodiments, the IP network design and configuration device 1000 can identify network controllers and, for each of the identified plurality of network controllers, identify respective BAS devices supervised by the network controller based on the received inputs. For example, the device identification module 1030 executed by the processor 615 of the device 1000 can be configured to identify network controllers (e.g., NAEs) and BAS devices supervised by the network controllers based on the received inputs. In some embodiments, the device 1000 takes the input information received by the input processing module and determines types, models, and quantities of managed switches that will comprise the BAS IP network infrastructure. In general, managed switches can provide the ability to configure, manage, and monitor the network (e.g., a local area network (LAN)) and offer advanced features to control the network traffic. In some embodiments, some of the advanced features can provide a higher level of network security. For example, in some embodiments, only the physical switch ports in a managed switch which are identified to be used for a specific purpose (e.g., to connect controllers, devices, network controllers, or other switches) are activated in the switch configuration file, and thus any unused ports or not activated ports cannot be used as unintended point of entry into the network. In some embodiments, user accounts with complex passwords for accessing the managed switches are configured by the IP network design and configuration tool and enforced by the managed switches. In contrast, an unmanaged switch simply allows devices connecting to it to communicate with each other, and is usually shipped with a fixed configuration and does not allow changes to that configuration. In some embodiments, as described herein in this disclosure, the switches (e.g., access switches, aggregation switches) that comprise the BAS IP network are managed switches.

In some embodiments, the device 1000 identifies or receives a list of network controllers (e.g., NAEs) to be used by the BAS system. For each network controller, the device 1000 determines how many devices are to be supervised by the network controller, and how the devices that the network controller supervises are to be connected to the BAS IP network (e.g., the number of redundant rings, the number of daisy chains, and the number of devices connected via a star/home run connection). In some embodiments, when the provided inputs are high level inputs, the device 1000 evenly distributes the devices across instances of the models of the network controllers specified by the user.

In some embodiments, the device identification module 1030 executed by the processor 1015 can determine whether a list of individual devices, a list of groups of devices, or high level inputs are specified based on the received inputs. In some embodiments, if a list of individual devices is specified as the input method, the device identification module 1030 executed by the processor 1015 determines, for each network controller in the list of individual devices, the number of BAS devices supervised by the network controller and how each BAS device supervised by the network controller is connected to the IP network. In some embodiments, if a list of groups of devices is specified as the input method, the device identification module 1030 executed by the processor 1015 can identify the plurality of network controllers by identifying a supervising network controller in each group of the list of groups. In some embodiments, devices in the same group share the same Ethernet connectivity method (e.g., are in the same daisy chain or ring of devices) and have the same supervising network controller. In some embodiments, if high level inputs are specified, the device identification module 1030 executed by the processor 1015 determines the number of network switches (e.g., access switches and aggregation switches, if applicable) that are to be used in the IP network and distributes a plurality of BAS devices across the network switches based on how the plurality of BAS devices are connected to the IP network.

In some embodiments, the IP network design and configuration device 1000 can, for each of the identified network controllers, allocate the respective BAS devices supervised by the network controller to one or more subnets and one or more access switches. For example, the subnet and switch allocation module 1035 executed by the processor 1015 can be configured to allocate BAS devices supervised by the identified network controllers to subnets and access switches. In some embodiments, field controllers and other BAS devices may be assigned to access switches. In some embodiments, the network controllers (e.g., NAEs) may or may not be assigned to access switches depending on user inputs. In some embodiments, based on user inputs, both the access switches and the network controllers may be connected directly to the IT network. In some embodiments, the number of devices that are allocated per subnet may be based on the network addressing architecture. For example, a Class C (/24) subnet can host up to 254 devices. In some embodiments, Class C subnet is used to accommodate a certain type of network controller (e.g., NAE 55). In some embodiments, other classes of subnets can be used. In some embodiments, the number of devices that are allocated per access switch is based on how the devices are connected to the BAS IP network (e.g., via star/home run, daisy chain, or redundant ring, etc.).

In some embodiments, the IP network design and configuration device 1000 can determine whether two or more subnets can be consolidated under a same switch, and if it is determined that two or more subnets can be consolidated under a same switch, consolidate the two or more subnets under the same switch. For example, the subnet consolidation module 1040 executed by the processor 1015 can be configured to determine whether two or more subnets can be consolidated under a same switch, and consolidate the two or more subnets under the same switch if it is determined that the two or more subnets can be consolidated under the same switch. Consolidating two or more subnets under the same switch can also be described as configuring switches to host multiple VLAN/subnets, in some embodiments. In some embodiments, in order to reduce the cost of the BAS IP network, the device 1000 determines if any of the subnets assigned to different access switches can be consolidated under the same access switch to reduce the number of access switches used for the BAS IP network. In some embodiments, the device 1000 determines whether to consolidate the subnets based on a plurality of criteria or rules. For example, the criteria or rules may include the number of remaining available switch ports of an access switch, the total number of MRP rings (if applicable), and the physical location of the devices. In some embodiments, in order to minimize cabling costs, the device 1000 may only consolidate subnets under the same access switch if the devices in those subnets are close to each other (e.g., on the same or adjacent floors of the building). In some embodiments, in order to reduce the total number of access switches used (and thereby reduce the overall BAS IP infrastructure costs), the subnet consolidation module 1040 may include logic to change the model of one or more the access switches to use a model with a higher port density, and thus may eliminate the need for an additional lower port density access switch.

In some embodiments, the IP network design and configuration device 1000 can perform IP planning for the IP network. For example, the IP planning module 1045 executed by the processor 1015 can be configured to perform IP planning for the IP network. In some embodiments, after determining the types, models, and quantities of the managed switches (e.g., managed access switches, managed aggregation switches), the device 1000 performs the IP planning for the BAS IP network. In some embodiments, the subnets in which the network controllers (e.g., NAEs) will reside are determined based on the user-specified BACnet broadcast behavior of the BAS system and the level of integration with the IT network. In some embodiments, the IP planning includes determining how the IP addresses in the network are allocated and laid out within the network, for example, what IP address range will be assigned to the BAS private network, what is the address range assigned to each subnet, what is the range of the IP addresses within each subnet which will be dynamically assigned to devices via DHCP, and what are the specific IP addresses to be reserved and assigned to the devices which require static IP addresses. In some embodiments, specific IP addresses are assigned to access switches and network controllers to ease/simplify the integration of the BAS IP network with an already deployed IT IP network. In some embodiments, static IP addresses are reserved and assigned to the network controllers (e.g., NAEs) and/or ADS/ADX. In some embodiments, dynamic IP addresses are reserved for specific devices or allocated for groups of devices. In some embodiments, devices supervised by the network controllers are assigned to subnets in the BAS private address space. In some embodiments, subnets can be assign to VLANs. In some embodiments, subnets and VLANs can be assigned to single switches or multiple switches, and possibly to specific ports on the switches.

In some embodiments, the IP network design and configuration device 1000 can generate a tailored configuration file tailored for each access switch in the IP network. For example, the configuration file generation module 1050 executed by the processor 1015 can be configured to generate a tailored configuration file tailored for each access switch in the IP network based on the determined network design. In some embodiments, an aggregation switch can be included in the BAS IP network, depending on the desired IP network architecture specified by the user. For example, the device 1000 can determine whether an aggregation switch is to be included in the IP network based on the desired IP network architecture specified by the user. In some embodiments, an aggregation switch may not be included in the BAS IP network, and the functionality of the aggregation switch may be configured on an access switch, just as in some embodiments that the access switch functionality may be configured on an aggregation switch. In some embodiments, when it is determined that the aggregation switch is to be included, the configuration file generation module 1050 executed by the processor 1015 can generate a tailored configuration file tailored for the aggregation switch. In some embodiments, the generated configuration file is stored in the memory of the IP network design and configuration device 1000. In some embodiments, the generated configuration file is stored in another device, such as a remote server that is able to automatically distribute the file to the proper switches as they appear on the network. In some embodiments, the generated configuration file is stored in the client device 935.

In some embodiments, within each configuration file, the device 1000 defines at least: (1) the Dynamic Host Configuration Protocol (DHCP) server for the BAS private subnet allocated to each access switch; (2) a Switch Virtual Interface (SVI) for the VLAN in the IT network, if applicable; (3) an SVI for each VLAN in the BAS IP network configured on the switch; (4) the configuration of each physical switch port on the switch; and (5) one or more Access Control Lists (ACLs) or other network security features. In some embodiments, an access switch may have multiple ACLs being configured. For example, multiple ingress ACLs can be configured for each physical interface (i.e., physical switch port). One ingress ACL and one egress ACL can be configured for each logic interface (i.e., a Switch Virtual Interface (SVI) for a VLAN). In some embodiments, the tailored configuration file also includes information of how messages are routed in order to reach their destinations.

In some embodiments, the configuration of each physical switch port on the switch further includes: (4a) the switch ports for the MRP rings of devices, if applicable; (4b) the switch ports for the daisy chains of devices, if applicable; (4c) the switch ports for the star/home run devices, if applicable; (4d) the switch ports used for rings governed by protocols other than MRP, such as Rapid Spanning Tree Protocol (RSTP); (4e) the switch ports for the NAE, if applicable; (4f) the switch ports for the ADS/ADX, if applicable; (4g) the switch ports to which a maintenance laptop can be connected for the purpose of debugging network issues; and (4h) the switch ports for connections to other access switches, the aggregation switch, or the IT network, depending on the IP network architecture specified by the user. In some embodiments, the ACLs further include: (5a) a media access control (MAC) ACL to allow inbound traffic only from devices with specific MAC prefixes; and (5b) IP ACLs to allow only specific traffic inbound or outbound based on the source and/or destination IP address and/or the source and/or destination logical port number value of an IP packet. In some embodiments, within the configuration file, the appropriate ACLs are applied to the physical switch ports as well as virtual switch ports (e.g., Switch Virtual Interfaces (SVIs)).

In some embodiments, the IP network design and configuration device 1000 can generate an installation file or document comprising instructions for installing the managed switches (e.g., managed access switches, managed aggregation switches) and BAS devices. For example, the installation document generation module 1055 executed by the processor 1015 can be configured to generate an installation document which provides instructions for the field technicians to install the managed switches, and BAS controllers and devices. In some embodiments, the installation document provides information about each managed switch (e.g., its model, configured hostname, and static IP address, etc.). The installation document can include information of how the BAS controllers and devices are to be connected to the access switches. For example, the installation document can include the configuration of each physical port of each access switch and the aggregation switch, if applicable, to aid field technicians to connect the BAS controllers and devices to the managed switches, and to connect the managed switches to each other or to the IT network. In some embodiments, a managed switch connects to another managed switch. In other embodiments, a managed switch may be connected directly to an IT network switch rather than to another managed switch. In some embodiments, the installation document can include information of how to configure the static IP address for each network controller (e.g., NAE) and the required configuration of static IP addresses in the network controllers. In some embodiments, when the BAS IP network is to be integrated with the IT network, the installation document can include information regarding what configuration changes are required to the IT network to allow the IT network and the BAS IP network to interoperate (e.g., the configuration of certain IT network switch ports, the default gateway address into the IT network referenced by the BAS IP network, route statements for routing packets to the BAS IP network, etc.).

In some embodiments, the IP network design and configuration device 1000 can generate content for an external media for an access switch when the access switch supports an external media interface. For example, the external media management module 1060 executed by the processor 1015 can be configured to generate and store content on the external media for an access switch responsive to that the access switch supports an external media interface. In some embodiments, for situations where a managed access switch supports an external media interface (e.g., a Secure Digital (SD) card), the device 1000 walks the user through the creation of the external media containing the configuration file and other files (e.g., the switch operating system (OS)). In some embodiments, the external media can be used to boot and configure the managed switches, thereby enabling the zero-touch deployment (e.g., deployment without login) of the BAS IP network infrastructure by field technicians.

Referring now to FIGS. 12A-12B, a process 1200 is shown for automatically configuring an IP network, according to an exemplary embodiment. In some embodiments, the process 1200 can be performed by the IP network design and configuration device 1000 or tool 905 to automatically configure an IP network. For example, the processor 1015 of the device 1000 can be configured to perform the process 1200. The process 1200 includes starting the automated design and configuration of an IP network process (step 1205). In some embodiments, step 1205 can start in response to a command or a request to design and configure an IP network for a BAS system.

The process 1200 can include receiving inputs (step 1210) comprising information specific to a building automation system (BAS) and information specific to the IP network. In some embodiments, the inputs can be received or obtained from one or more storage devices or databases, or another device. In some embodiments, the information specific to the BAS can include, for example, information of the BAS devices that are to be connected via the BAS IP network, the relationships between the devices (e.g., which controllers will be supervised by a network controller (e.g., NAE), the required behavior of the BAS system (e.g., how the system should report errors, the physical location of the devices/controllers (e.g., the floor of the building on which they will be installed)), and attributes of the BAS system (e.g., what values should be used for the BACnet port numbers). In some embodiments, the information specific to the IP network can include information specifying the relationship between the BAS IP network and the customer's IT network (e.g., whether the BAS IP network is a separate network from the IT network; if not, the level of integration with the customer's IT network) and how the devices will be connected to the IP network (e.g., via star/home run, daisy chain, or redundant ring (the information specific to the connected devices can include protocol information such as BACnet and Media Redundancy Protocol (MRP) ring)). For example, if the BAS IP network is to be integrated with the customer's IT network, at least a limited amount of information regarding how the systems are integrated are to be provided as inputs.

The process 1200 can include determining the device input method to assign devices to network controllers (step 1215). In some embodiments, the device input method can be a list of individual devices, a list of groups of devices, or high level inputs. For example, the processor 1015 of the device 1000 can determine whether a list of individual devices, a list of groups of devices, or high level inputs are specified based on the received inputs.

The process 1200 can include determining, for each network controller in the list of individual devices, a number of BAS devices supervised by the network controller and how each BAS device supervised by the network controller is connected to the IP network (step 1220), responsive to a list of individual devices being specified. For example, the method can use specific details of each device included in the list of individual devices to determine or identify the number of BAS devices supervised by the network controller and how each BAS device supervised by the network controller is connected to the IP network. The process 1200 can include identifying the plurality of network controllers by identifying a supervising network controller in each group of the list of groups (step 1225), responsive to the list of groups of devices being specified. In some embodiments, devices in the same group share the same Ethernet connectivity method (e.g., are in the same daisy chain or ring of devices) and have the same supervising network controller. The process 1200 can include, responsive to that high level inputs are specified, determining the number of network switches (e.g., access switches and aggregation switches, if applicable) that are to be used in the IP network and distributing a plurality of BAS devices across the network switches based on how the plurality of BAS devices are connected to the IP network (step 1228). For example, the method can use high level inputs relating to the information specific to the BAS and the information specific to the IP network to determine or identify the number of network controllers that are to be used in the IP network and distribute the BAS devices across the network controllers based on how the plurality of BAS devices are connected to the IP network. In some embodiments, the BAS devices may be evenly distributed across the network controllers.

The process 1200 can include, for each of the network controllers, allocating the respective BAS devices supervised by the network controller to one or more subnets and one or more access switches (step 1230). In some embodiments, field controllers and other BAS devices may be assigned to access switches. The network controllers (e.g., NAEs) may or may not be assigned to access switches depending on user inputs. In some embodiments, based on user inputs, both the access switches and the network controllers may be connected directly to the IT network. In some embodiments, the number of devices that are allocated per subnet may be based on the network addressing architecture. For example, a Class C (/24) subnet can host up to 254 devices. In some embodiments, the number of devices that are allocated per access switch is based on how the devices are connected to the BAS IP network (e.g., via star/home run, daisy chain, or MRP ring, etc.).

The process 1200 can include, responsive to determining that at least two subnets can be consolidated under a same switch, consolidate the at least two subnets under the same switch (step 1235). Consolidating two or more subnets under the same switch can also be described as configuring switches to host multiple VLAN/subnets, in some embodiments. In some embodiments, in order to reduce the cost of the BAS IP network, the processor 1015 of the processing circuit 1010 can determine if any of the subnets assigned to different access switches can be consolidated under the same access switch to reduce the number of switches used for the BAS IP network. In some embodiments, the determination of whether to consolidate the subnets can be based on a plurality of criteria or rules. For example, the criteria or rules may include the number of remaining available switch ports of an access switch, the total number of MRP rings (if applicable), and the physical location of the devices. In some embodiments, in order to minimize cabling and other network infrastructure costs, subnets may be consolidated under the same access switch if the devices in those subnets are close to each other (e.g., on the same or adjacent floors of the building). In some embodiments, in order to reduce the total number of access switches used (and thereby reduce the overall BAS IP infrastructure costs), the model of one or more the access switches may be changed to use a model with a higher port density to eliminate the need for an additional lower port density access switch.

The process 1200 can include performing IP planning for the IP network (step 1240). In some embodiments, after determining the types, models, and quantities of the switches to be used for the BAS IP network, the processor 1015 of the processing circuit 1010 can perform IP planning for the BAS IP network. In some embodiments, the subnets in which the network controllers (e.g., NAEs) will reside are determined based on the user-specified BACnet broadcast behavior of the BAS system and the level of integration with the IT network. In some embodiments, the IP planning includes determining how the IP address in the network are allocated and laid out within the network, for example, what IP address range will be assigned to the BAS private network, what is the address range assigned to each subnet, what are the range of the IP addresses within each subnet which will be dynamically assigned to devices via DHCP, and what are the specific IP addresses to be assigned to the devices which require static IP addresses. In some embodiments, specific IP addresses are reserved and assigned to access switches and network controllers to ease/simplify the integration of the BAS IP network with an already deployed IT IP network. In some embodiments, static IP addresses are reserved and assigned to the network controllers (e.g., NAEs) and/or ADS/ADX. In some embodiments, dynamic IP addresses are reserved for specific devices or allocated for groups of devices. In some embodiments, devices supervised by the network controllers are assigned to subnets in the BAS private address space. In some embodiments, subnets can be assign to VLANs. In some embodiments, subnets and VLANs can be assigned to single switches or multiple switches, and possibly to specific ports on the switches.

The process 1200 can include generating a tailored configuration file tailored for each access switch in the IP network (step 1245). In some embodiments, a tailored configuration file for each access switch can be generated, which includes at least information of (1) the DHCP server for the BAS private subnet allocated to each access switch; (2) a Switch Virtual Interface (SVI) for the VLAN in the IT network, if applicable; (3) an SVI for each VLAN in the BAS IP network configured on the switch; (4) the configuration of each physical switch port on the switch; and (5) one or more Access Control Lists (ACLs). In some embodiments, an access switch may have multiple ACLs being configured. For example, multiple ingress ACLs can be configured for each physical interface (i.e., physical switch port). One ingress ACL and one egress ACL can be configured for each logic interface (i.e., a Switch Virtual Interface (SVI) for a VLAN). In some embodiments, the tailored configuration file also includes information of how messages are routed in order to reach their destinations.

The process 1200 can include determining whether an aggregation switch is to be included in the IP network (step 1250). In some embodiments, an aggregation switch can be included in the BAS IP network, depending on the desired IP network architecture specified by the user. In some embodiments, an aggregation switch may not be included in the BAS IP network, and the functionality of the aggregation switch may be configured on an access switch, just as in some embodiments that the access switch functionality may be configured on an aggregation switch. In some embodiments, when it is determined that the aggregation switch is to be included, a tailored configuration file can be generated for the aggregation switch (step 1255). In some embodiments, the tailored configuration file for the aggregation switch can be similar to the configuration file for the access switch, as described herein above in relation to step 1245.

The process 1200 can include generating an installation document (step 1260). In some embodiments, the processor 1015 of the processing circuit 1010 can generate an installation document which provides instructions for the field technicians to install the managed switches (e.g., managed access switches, managed aggregation switches), and BAS controllers and devices. In some embodiments, the installation file can include instructions of how the BAS controllers and devices are to be connected to the managed switches, how a managed switch is to be connected to another managed switch and/or an IT network switch, the required configuration of static IP addresses in the network controllers (e.g., NAEs), and configuration changes, if any, required to the IT network. In some embodiments, a managed switch connects to another managed switch. In other embodiments, a managed switch may be connected directly to an IT network switch rather than to another managed switch.

The process 1200 can include determining whether a switch is to be loaded via an external media device (step 1265). If the switch is to be loaded via an external media interface, the processor 1015 generates and stores content on the external media for the switch (step 1270). In some embodiments, for situations where a managed access switch supports an external media interface (e.g., a Secure Digital (SD) card), the process 1200 walks the user through the creation of the external media containing the configuration file and other files (e.g., the switch operating system (OS)). In some embodiments, the external media can be used to boot and configure the managed switches, thereby enabling the zero-touch deployment (e.g., deployment without login) of the BAS IP network infrastructure by field technicians. In some embodiments, process 1200 may end at step 1275.

In some embodiments, a bill of materials for the required network infrastructure (e.g., network switches, power supplies, power cables, service contracts, Ethernet cable counts, etc.) can be generated. For example, a total number of network switches (e.g., access switches, aggregation switches, if applicable) and/or other materials required for the IP network are calculated and determined, and the bill of materials for the required network infrastructure is generated based on the calculated total number of network switches and/or other materials required for the IP network.

Systems and methods as described herein in this disclosure provide advantages over the traditional methods for planning and configuring an IP network. Traditional methods for planning and configuring an IP network are generally highly manual processes to perform the network planning for the deployment of an IP network. However, none of the traditional methods can generate a complete configuration for a managed switch or set of managed switches based on a network design. In contrast, as described herein above in this disclosure, systems and methods of the present disclosure takes a holistic approach in designing and configuring the IP network for an IP-based BAS system. Because systems and methods of the present disclosure follow a defined set of design rules, the BAS IP network can be deployed by existing HVAC field personnel with little to no additional IP training, thereby minimizing installation costs. Furthermore, the network designs are consistent across jobs, making the IP network easier to troubleshoot if problems occur, thereby reducing maintenance costs.

Moreover, in the traditional systems, the design and configuration of IP networks have fallen under the purview of IT, and the BAS personnel generally do not have the skillset to design or deploy an IP network. Systems and methods as described herein allows BAS (e.g., HVAC) field technicians to configure and deploy the IP infrastructure for an IP-based BAS system without having to log into the managed switches which comprise the BAS IP network. Such systems and methods of the present disclosure allow the BAS IP network to be created and deployed by the BAS field personnel with little to no IT training.

Configuration of Exemplary Embodiments

The construction and arrangement of the systems and methods as shown in the various exemplary embodiments are illustrative only. Although only a few embodiments have been described in detail in this disclosure, many modifications are possible (e.g., variations in sizes, dimensions, structures, shapes and proportions of the various elements, values of parameters, mounting arrangements, use of materials, colors, orientations, etc.). For example, the position of elements may be reversed or otherwise varied and the nature or number of discrete elements or positions may be altered or varied. Accordingly, all such modifications are intended to be included within the scope of the present disclosure. The order or sequence of any process or method steps may be varied or re-sequenced according to alternative embodiments. Additional protocols for network management and operation, methods for securing switch interfaces, and so on, are not precluded. Other substitutions, modifications, changes, and omissions may be made in the design, operating conditions and arrangement of the exemplary embodiments without departing from the scope of the present disclosure.

The present disclosure contemplates methods, systems and program products on any machine-readable media for accomplishing various operations. The embodiments of the present disclosure may be implemented using existing computer processors, or by a special purpose computer processor for an appropriate system, incorporated for this or another purpose, or by a hardwired system. Embodiments within the scope of the present disclosure include program products comprising machine-readable media for carrying or having machine-executable instructions or data structures stored thereon. Such machine-readable media can be any available media that can be accessed by a general purpose or special purpose computer or other machine with a processor. By way of example, such machine-readable media can comprise RAM, ROM, EPROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code in the form of machine-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer or other machine with a processor. Combinations of the above are also included within the scope of machine-readable media. Machine-executable instructions include, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing machines to perform a certain function or group of functions.

Although the figures show a specific order of method steps, the order of the steps may differ from what is depicted. Also two or more steps may be performed concurrently or with partial concurrence. Such variation will depend on the software and hardware systems chosen and on designer choice. All such variations are within the scope of the disclosure. Likewise, software implementations could be accomplished with standard programming techniques with rule based logic and other logic to accomplish the various connection steps, processing steps, comparison steps and decision steps.

SYSTEMS AND METHODS FOR AUTOMATICALLY CONFIGURING AN IP NETWORK

Information

Publication Number

Date Filed

Date Published

Inventors

Original Assignees

CPC

International Classifications

Abstract

Description

Claims

CROSS-REFERENCE TO RELATED APPLICATIONS

Provisional Applications (1)