Patent ID: 12206523

DETAILED DESCRIPTION

Overview

Referring generally to the FIGURES, systems and methods for determining the topology of an Ethernet ring are shown, according to various exemplary embodiments. The systems may include an Ethernet ring topology generator (RTG), a ring supervisor, and a number of devices within the ring for which the topology is to be determined. In some embodiments, the methods described herein can leverage information made available to the ring devices by the ring management protocol in use without requiring modification of the ring management protocol itself. Previous systems and methods for determining the topology of an Ethernet ring or the like without requiring modification of the ring management protocol are described in U.S. Pat. No. 10,116,517, filed May 1, 2017, and U.S. patent application Ser. No. 16/206,614, filed Nov. 11, 2018, both of which are incorporated by reference herein in their entirety.

In some embodiments, systems and methods described herein provide a mechanism to accurately determine the order of the devices within the ring and how the devices are connected to one another (e.g., which switch port on a device is connected to a specific neighboring device.) This topology of the ring may be generated using information made available to the ring devices by the ring management protocol in use without requiring modification to the ring management protocol itself.

In some embodiments, the topology of the ring is determined by disabling a first port of a particular device in the ring (e.g., Device A) and detecting a terminated link at a first port of another device in the ring (e.g., Device B). Device B may send a message to the RTG in response to detecting the terminated link at the first port of Device B. The message may indicate that the first port of Device B is connected to a previous device relative to Device B. The “previous device” relative to Device B can be defined as the device that most recently disabled one of its ports, causing the terminated link to be detected at Device B. In this example, Device A is the previous device relative to Device B. However, the identity of the previous device (i.e., the fact that the previous device is Device A) but does not need to be known by Device B. The message sent from Device B to the RTG may simply inform the RTG that the first port of Device B is connected to a previous device, which may be unidentified from the perspective of Device B. However, the RTG is aware that Device A is the previous device relative to Device B and can therefore determine that the first port of Device B is connected to the first port of Device A. The RTG can make this determination based on two pieces of information: (1) the message indicating that the first port of Device B is connected to the previous device relative to Device B and (2) an indication (e.g., data, information, etc.) possessed by the RTG that Device A is the previous device relative to Device B.

This process can then be repeated by disabling the second port of Device B and detecting a terminated link at a first port of yet another device (e.g., Device C). Device C may send a message to the RTG in response to detecting the terminated link at the first port of Device C. The message may indicate that the first port of Device C is connected to a previous device relative to Device C. The RTG can make this determination based on two pieces of information: (1) the message indicating that the first port of Device C is connected to the previous device relative to Device C and (2) an indication (e.g., data, information, etc.) possessed by the RTG that Device B is the previous device relative to Device C. This process can be repeated for each device in the ring until the entire topology of the ring is generated by the RTG.

It should be understood that the term “in response to” as used herein does not necessarily require an immediate action following an event, but rather only an action that is triggered by the previous event, even if the responsive action is delayed and/or other events occur between the triggering event and the responsive action. For example, the message sent from Device B to the RTG “in response to” detecting the terminated link at the first port of Device B may be sent from Device B to the RTG immediately upon detecting the terminated link at Device B or alternatively after the first port of Device B transitions back to an active or unterminated state (e.g., after re-enabling the first port of Device A). The message sent from Device B to the RTG is “in response to” detecting the terminated link at Device B in both of these scenarios, as well as any other scenario in which detecting the terminated link at Device B causes the message to be sent from Device B to the RTG, even if the message is not sent until other events occur after detecting the terminated link at Device B.

Advantageously, the methods described herein require significantly less messaging between the RTG application and the ring devices in order to generate the topology of the ring. In some embodiments, the embodiments descried herein may only require the exchange of 3+2n messages to determine the topology of the ring, where n is the number of devices within the ring. The reduction in messaging speeds up the time it takes to generate the ring topology as well as reduces the potential for a lost message, which could cause the ring topology generation process to fail.

Advantageously, the RTG application interfaces with all of the ring devices in a similar manner, and the behavior of the devices remains the same whether the ring device is a ring client or a ring manager, further simplifying the topology generation process. Additionally, the methods described herein do not require the RTG application to reside outside of the ring for which the topology is to be determined. The methods are applicable to any Ethernet ring where the associated ring management protocol makes a ring identifier and the open/closed status of the ring available to the ring devices. Further, once the topology of the ring has been generated, the topology can be used in troubleshooting an MRP ring when errors or faults occur. These and other features of the system and methods are described in greater detail below.

Building Management System and HVAC System

Referring now toFIGS.1-4, an exemplary building management system (BMS) and a heating, ventilation, and air conditioning (HVAC) system in which the systems and methods of the present disclosure can be implemented are shown, according to an exemplary embodiment. Referring particularly toFIG.1, a perspective view of a building10is shown. Building10is served by a BMS. A BMS is, in general, a system of devices configured to control, monitor, and manage equipment in or around a building or building area. A BMS 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 BMS that serves building10includes an HVAC system100. HVAC system100can 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 building10. For example, HVAC system100is shown to include a waterside system120and an airside system130. Waterside system120can provide a heated or chilled fluid to an air handling unit of airside system130. Airside system130can use the heated or chilled fluid to heat or cool an airflow provided to building10. An exemplary waterside system and airside system which can be used in HVAC system100are described in greater detail with reference toFIGS.2-3.

HVAC system100is shown to include a chiller102, a boiler104, and a rooftop air handling unit (AHU)106. Waterside system120can use boiler104and chiller102to heat or cool a working fluid (e.g., water, glycol, etc.) and can circulate the working fluid to AHU106. In various embodiments, the HVAC devices of waterside system120can be located in or around building10(as shown inFIG.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 can be heated in boiler104or cooled in chiller102, depending on whether heating or cooling is required in building10. Boiler104can add heat to the circulated fluid, for example, by burning a combustible material (e.g., natural gas) or using an electric heating element. Chiller102can 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 chiller102and/or boiler104can be transported to AHU106via piping108.

AHU106can place the working fluid in a heat exchange relationship with an airflow passing through AHU106(e.g., via one or more stages of cooling coils and/or heating coils). The airflow can be, for example, outside air, return air from within building10, or a combination of both. AHU106can transfer heat between the airflow and the working fluid to provide heating or cooling for the airflow. For example, AHU106can 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 can then return to chiller102or boiler104via piping110.

Airside system130can deliver the airflow supplied by AHU106(i.e., the supply airflow) to building10via air supply ducts112and can provide return air from building10to AHU106via air return ducts114. In some embodiments, airside system130includes multiple variable air volume (VAV) units116. For example, airside system130is shown to include a separate VAV unit116on each floor or zone of building10. VAV units116can include dampers or other flow control elements that can be operated to control an amount of the supply airflow provided to individual zones of building10. In other embodiments, airside system130delivers the supply airflow into one or more zones of building10(e.g., via supply ducts112) without using intermediate VAV units116or other flow control elements. AHU106can include various sensors (e.g., temperature sensors, pressure sensors, etc.) configured to measure attributes of the supply airflow. AHU106can receive input from sensors located within AHU106and/or within the building zone and can adjust the flow rate, temperature, or other attributes of the supply airflow through AHU106to achieve set-point conditions for the building zone.

Referring now toFIG.2, a block diagram of a waterside system200is shown, according to an exemplary embodiment. In various embodiments, waterside system200can supplement or replace waterside system120in HVAC system100or can be implemented separate from HVAC system100. When implemented in HVAC system100, waterside system200can include a subset of the HVAC devices in HVAC system100(e.g., boiler104, chiller102, pumps, valves, etc.) and can operate to supply a heated or chilled fluid to AHU106. The HVAC devices of waterside system200can be located within building10(e.g., as components of waterside system120) or at an offsite location such as a central plant.

InFIG.2, waterside system200is shown as a central plant having a plurality of subplants202-212. Subplants202-212are shown to include a heater subplant202, a heat recovery chiller subplant204, a chiller subplant206, a cooling tower subplant208, a hot thermal energy storage (TES) subplant210, and a cold thermal energy storage (TES) subplant212. Subplants202-212consume 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 subplant202can be configured to heat water in a hot water loop214that circulates the hot water between heater subplant202and building10. Chiller subplant206can be configured to chill water in a cold water loop216that circulates the cold water between chiller subplant206and the building10. Heat recovery chiller subplant204can be configured to transfer heat from cold water loop216to hot water loop214to provide additional heating for the hot water and additional cooling for the cold water. Condenser water loop218can absorb heat from the cold water in chiller subplant206and reject the absorbed heat in cooling tower subplant208or transfer the absorbed heat to hot water loop214. Hot TES subplant210and cold TES subplant212can store hot and cold thermal energy, respectively, for subsequent use.

Hot water loop214and cold water loop216can deliver the heated and/or chilled water to air handlers located on the rooftop of building10(e.g., AHU106) or to individual floors or zones of building10(e.g., VAV units116). 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 can be delivered to individual zones of building10to serve the thermal energy loads of building10. The water then returns to subplants202-212to receive further heating or cooling.

Although subplants202-212are 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.) can be used in place of or in addition to water to serve the thermal energy loads. In other embodiments, subplants202-212can provide heating and/or cooling directly to the building or campus without requiring an intermediate heat transfer fluid. These and other variations to waterside system200are within the teachings of the present invention.

Each of subplants202-212can include a variety of equipment configured to facilitate the functions of the subplant. For example, heater subplant202is shown to include a plurality of heating elements220(e.g., boilers, electric heaters, etc.) configured to add heat to the hot water in hot water loop214. Heater subplant202is also shown to include several pumps222and224configured to circulate the hot water in hot water loop214and to control the flow rate of the hot water through individual heating elements220. Chiller subplant206is shown to include a plurality of chillers232configured to remove heat from the cold water in cold water loop216. Chiller subplant206is also shown to include several pumps234and236configured to circulate the cold water in cold water loop216and to control the flow rate of the cold water through individual chillers232.

Heat recovery chiller subplant204is shown to include a plurality of heat recovery heat exchangers226(e.g., refrigeration circuits) configured to transfer heat from cold water loop216to hot water loop214. Heat recovery chiller subplant204is also shown to include several pumps228and230configured to circulate the hot water and/or cold water through heat recovery heat exchangers226and to control the flow rate of the water through individual heat recovery heat exchangers226. Cooling tower subplant208is shown to include a plurality of cooling towers238configured to remove heat from the condenser water in condenser water loop218. Cooling tower subplant208is also shown to include several pumps240configured to circulate the condenser water in condenser water loop218and to control the flow rate of the condenser water through individual cooling towers238.

Hot TES subplant210is shown to include a hot TES tank242configured to store the hot water for later use. Hot TES subplant210can also include one or more pumps or valves configured to control the flow rate of the hot water into or out of hot TES tank242. Cold TES subplant212is shown to include cold TES tanks244configured to store the cold water for later use. Cold TES subplant212can also include one or more pumps or valves configured to control the flow rate of the cold water into or out of cold TES tanks244.

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

Referring now toFIG.3, a block diagram of an airside system300is shown, according to an exemplary embodiment. In various embodiments, airside system300can supplement or replace airside system130in HVAC system100or can be implemented separate from HVAC system100. When implemented in HVAC system100, airside system300can include a subset of the HVAC devices in HVAC system100(e.g., AHU106, VAV units116, ducts112-114, fans, dampers, etc.) and can be located in or around building10. Airside system300can operate to heat or cool an airflow provided to building10using a heated or chilled fluid provided by waterside system200.

InFIG.3, airside system300is 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, AHU302can receive return air304from building zone306via return air duct308and can deliver supply air310to building zone306via supply air duct312. In some embodiments, AHU302is a rooftop unit located on the roof of building10(e.g., AHU106as shown inFIG.1) or otherwise positioned to receive return air304and outside air314. AHU302can be configured to operate an exhaust air damper316, mixing damper318, and outside air damper320to control an amount of outside air314and return air304that combine to form supply air310. Any return air304that does not pass through mixing damper318can be exhausted from AHU302through exhaust damper316as exhaust air322.

Each of dampers316-320can be operated by an actuator. For example, exhaust air damper316can be operated by actuator324, mixing damper318can be operated by actuator326, and outside air damper320can be operated by actuator328. Actuators324-328can communicate with an AHU controller330via a communications link332. Actuators324-328can receive control signals from AHU controller330and can provide feedback signals to AHU controller330. Feedback signals can 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 actuators324-328), status information, commissioning information, configuration settings, calibration data, and/or other types of information or data that can be collected, stored, or used by actuators324-328. AHU controller330can 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 actuators324-328

Still referring toFIG.3, AHU302is shown to include a cooling coil334, a heating coil336, and a fan338positioned within supply air duct312. Fan338can be configured to force supply air310through cooling coil334and/or heating coil336and provide supply air310to building zone306. AHU controller330can communicate with fan338via communications link340to control a flow rate of supply air310. In some embodiments, AHU controller330controls an amount of heating or cooling applied to supply air310by modulating a speed of fan338.

Cooling coil334can receive a chilled fluid from waterside system200(e.g., from cold water loop216) via piping342and can return the chilled fluid to waterside system200via piping344. Valve346can be positioned along piping342or piping344to control a flow rate of the chilled fluid through cooling coil334. In some embodiments, cooling coil334includes multiple stages of cooling coils that can be independently activated and deactivated (e.g., by AHU controller330, by BMS controller366, etc.) to modulate an amount of cooling applied to supply air310.

Heating coil336can receive a heated fluid from waterside system200(e.g., from hot water loop214) via piping348and can return the heated fluid to waterside system200via piping350. Valve352can be positioned along piping348or piping350to control a flow rate of the heated fluid through heating coil336. In some embodiments, heating coil336includes multiple stages of heating coils that can be independently activated and deactivated (e.g., by AHU controller330, by BMS controller366, etc.) to modulate an amount of heating applied to supply air310.

Each of valves346and352can be controlled by an actuator. For example, valve346can be controlled by actuator354and valve352can be controlled by actuator356. Actuators354-356can communicate with AHU controller330via communications links358-360. Actuators354-356can receive control signals from AHU controller330and can provide feedback signals to AHU controller330. In some embodiments, AHU controller330receives a measurement of the supply air temperature from a temperature sensor362positioned in supply air duct312(e.g., downstream of cooling coil334and/or heating coil336). AHU controller330can also receive a measurement of the temperature of building zone306from a temperature sensor364located in building zone306.

In some embodiments, AHU controller330operates valves346and352via actuators354-356to modulate an amount of heating or cooling provided to supply air310(e.g., to achieve a set-point temperature for supply air310or to maintain the temperature of supply air310within a set-point temperature range). The positions of valves346and352affect the amount of heating or cooling provided to supply air310by cooling coil334or heating coil336and may correlate with the amount of energy consumed to achieve a desired supply air temperature. AHU controller330can control the temperature of supply air310and/or building zone306by activating or deactivating coils334-336, adjusting a speed of fan338, or a combination thereof.

Still referring toFIG.3, airside system300is shown to include a building management system (BMS) controller366and a client device368. BMS controller366can 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 system300, waterside system200, HVAC system100, and/or other controllable systems that serve building10. BMS controller366can communicate with multiple downstream building systems or subsystems (e.g., HVAC system100, a security system, a lighting system, waterside system200, etc.) via a communications link370according to like or disparate protocols (e.g., LON, BACnet, etc.). In various embodiments, AHU controller330and BMS controller366can be separate (as shown inFIG.3) or integrated. In an integrated implementation, AHU controller330can be a software module configured for execution by a processor of BMS controller366.

In some embodiments, AHU controller330receives information from BMS controller366(e.g., commands, setpoints, operating boundaries, etc.) and provides information to BMS controller366(e.g., temperature measurements, valve or actuator positions, operating statuses, diagnostics, etc.). For example, AHU controller330can provide BMS controller366with temperature measurements from temperature sensors362-364, equipment on/off states, equipment operating capacities, and/or any other information that can be used by BMS controller366to monitor or control a variable state or condition within building zone306.

Client device368can 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 system100, its subsystems, and/or devices. Client device368can be a computer workstation, a client terminal, a remote or local interface, or any other type of user interface device. Client device368can be a stationary terminal or a mobile device. For example, client device368can 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 device368can communicate with BMS controller366and/or AHU controller330via communications link372.

Referring now toFIG.4, a block diagram of a building management system (BMS)400is shown, according to an exemplary embodiment. BMS400can be implemented in building10to automatically monitor and control various building functions. BMS400is shown to include BMS controller366and a plurality of building subsystems428. Building subsystems428are shown to include a building electrical subsystem434, an information communication technology (ICT) subsystem436, a security subsystem438, a HVAC subsystem440, a lighting subsystem442, a lift/escalators subsystem432, and a fire safety subsystem430. In various embodiments, building subsystems428can include fewer, additional, or alternative subsystems. For example, building subsystems428can 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 building10. In some embodiments, building subsystems428include waterside system200and/or airside system300, as described with reference toFIGS.2-3.

Each of building subsystems428can include any number of devices, controllers, and connections for completing its individual functions and control activities. HVAC subsystem440can include many of the same components as HVAC system100, as described with reference toFIGS.1-3. For example, HVAC subsystem440can 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 building10. Lighting subsystem442can 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 subsystem438can include occupancy sensors, video surveillance cameras, digital video recorders, video processing servers, intrusion detection devices, access control devices (e.g., card access, etc.) and servers, or other security-related devices.

Still referring toFIG.4, BMS controller366is shown to include a communications interface407and a BMS interface409. Communications interface407can facilitate communications between BMS controller366and external applications (e.g., monitoring and reporting applications422, enterprise control applications426, remote systems and applications444, applications residing on client devices448, etc.) for allowing user control, monitoring, and adjustment to BMS controller366and/or building subsystems428. Communications interface407can also facilitate communications between BMS controller366and client devices448. BMS interface409can facilitate communications between BMS controller366and building subsystems428(e.g., HVAC, lighting security, lifts, power distribution, business, etc.).

Interfaces407,409can be or include wired or wireless communications interfaces (e.g., jacks, antennas, transmitters, receivers, transceivers, wire terminals, etc.) for conducting data communications with building subsystems428or other external systems or devices. In various embodiments, communications via interfaces407,409can be direct (e.g., locally wired or wireless communications) or via a communications network446(e.g., a WAN, the Internet, a cellular network, etc.). For example, interfaces407,409can include an Ethernet card and port for sending and receiving data via an Ethernet-based communications link or network. In another example, the interfaces407,409can include a Wi-Fi transceiver for communicating via a wireless communications network. In another example, one or more of interfaces407,409can include cellular or mobile phone communications transceivers. In one embodiment, communications interface407is a power line communications interface and BMS interface409is an Ethernet interface. In other embodiments, communications interface407and BMS interface409are Ethernet interfaces or are the same Ethernet interface.

Still referring toFIG.4, BMS controller366is shown to include a processing circuit404including a processor406and memory408. Processing circuit404can be communicably connected to BMS interface409and/or communications interface407such that processing circuit404and the various components thereof can send and receive data via interfaces407,409. Processor406can 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.

Memory408(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. Memory408can be or include volatile memory or non-volatile memory. Memory408can 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, memory408is communicably connected to processor406via processing circuit404and includes computer code for executing (e.g., by processing circuit404and/or processor406) one or more processes described herein.

In some embodiments, BMS controller366is implemented within a single computer (e.g., one server, one housing, etc.). In various other embodiments BMS controller366can be distributed across multiple servers or computers (e.g., that can exist in distributed locations). Further, whileFIG.4shows applications422and426as existing outside of BMS controller366, in some embodiments, applications422and426can be hosted within BMS controller366(e.g., within memory408).

Still referring toFIG.4, memory408is shown to include an enterprise integration layer410, an automated measurement and validation (AM&V) layer412, a demand response (DR) layer414, a fault detection and diagnostics (FDD) layer416, an integrated control layer418, and a building subsystem integration later420. Layers410-420can be configured to receive inputs from building subsystems428and other data sources, determine optimal control actions for building subsystems428based on the inputs, generate control signals based on the optimal control actions, and provide the generated control signals to building subsystems428. The following paragraphs describe some of the general functions performed by each of layers410-420in BMS400.

Enterprise integration layer410can be configured to serve clients or local applications with information and services to support a variety of enterprise-level applications. For example, enterprise control applications426can 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 applications426can also or alternatively be configured to provide configuration GUIs for configuring BMS controller366. In yet other embodiments, enterprise control applications426can work with layers410-420to optimize building performance (e.g., efficiency, energy use, comfort, or safety) based on inputs received at interface407and/or BMS interface409.

Building subsystem integration layer420can be configured to manage communications between BMS controller366and building subsystems428. For example, building subsystem integration layer420can receive sensor data and input signals from building subsystems428and provide output data and control signals to building subsystems428. Building subsystem integration layer420can also be configured to manage communications between building subsystems428. Building subsystem integration layer420translate communications (e.g., sensor data, input signals, output signals, etc.) across a plurality of multi-vendor/multi-protocol systems.

Demand response layer414can 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 building10. The optimization can be based on time-of-use prices, curtailment signals, energy availability, or other data received from utility providers, distributed energy generation system424, from energy storage427(e.g., hot TES242, cold TES244, etc.), or from other sources. Demand response layer414can receive inputs from other layers of BMS controller366(e.g., building subsystem integration layer420, integrated control layer418, etc.). The inputs received from other layers can 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 can 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 layer414includes control logic for responding to the data and signals it receives. These responses can include communicating with the control algorithms in integrated control layer418, changing control strategies, changing setpoints, or activating/deactivating building equipment or subsystems in a controlled manner. Demand response layer414can also include control logic configured to determine when to utilize stored energy. For example, demand response layer414can determine to begin using energy from energy storage427just prior to the beginning of a peak use hour.

In some embodiments, demand response layer414includes 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 layer414uses equipment models to determine an optimal set of control actions. The equipment models can include, for example, thermodynamic models describing the inputs, outputs, and/or functions performed by various sets of building equipment. Equipment models can represent collections of building equipment (e.g., subplants, chiller arrays, etc.) or individual devices (e.g., individual chillers, heaters, pumps, etc.).

Demand response layer414can further include or draw upon one or more demand response policy definitions (e.g., databases, XML files, etc.). The policy definitions can 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 can 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 can 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 set-point before returning to a normally scheduled set-point, 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 layer418can be configured to use the data input or output of building subsystem integration layer420and/or demand response layer414to make control decisions. Due to the subsystem integration provided by building subsystem integration layer420, integrated control layer418can integrate control activities of the building subsystems428such that the subsystems428behave as a single integrated supersystem. In an exemplary embodiment, integrated control layer418includes control logic that uses inputs and outputs from a plurality of building subsystems428to provide greater comfort and energy savings relative to the comfort and energy savings that separate subsystems could provide alone. For example, integrated control layer418can 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 layer420.

Integrated control layer418is shown to be logically below demand response layer414. Integrated control layer418can be configured to enhance the effectiveness of demand response layer414by enabling building subsystems428and their respective control loops to be controlled in coordination with demand response layer414. This configuration may advantageously reduce disruptive demand response behavior relative to conventional systems. For example, integrated control layer418can be configured to assure that a demand response-driven upward adjustment to the set-point 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 layer418can be configured to provide feedback to demand response layer414so that demand response layer414checks that constraints (e.g., temperature, lighting levels, etc.) are properly maintained even while demanded load shedding is in progress. The constraints can also include set-point or sensed boundaries relating to safety, equipment operating limits and performance, comfort, fire codes, electrical codes, energy codes, and the like. Integrated control layer418is also logically below fault detection and diagnostics layer416and automated measurement and validation layer412. Integrated control layer418can 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) layer412can be configured to verify that control strategies commanded by integrated control layer418or demand response layer414are working properly (e.g., using data aggregated by AM&V layer412, integrated control layer418, building subsystem integration layer420, FDD layer416, or otherwise). The calculations made by AM&V layer412can be based on building system energy models and/or equipment models for individual BMS devices or subsystems. For example, AM&V layer412can compare a model-predicted output with an actual output from building subsystems428to determine an accuracy of the model.

Fault detection and diagnostics (FDD) layer416can be configured to provide on-going fault detection for building subsystems428, building subsystem devices (i.e., building equipment), and control algorithms used by demand response layer414and integrated control layer418. FDD layer416can receive data inputs from integrated control layer418, directly from one or more building subsystems or devices, or from another data source. FDD layer416can automatically diagnose and respond to detected faults. The responses to detected or diagnosed faults can 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 layer416can 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 layer420. In other exemplary embodiments, FDD layer416is configured to provide “fault” events to integrated control layer418which executes control strategies and policies in response to the received fault events. According to an exemplary embodiment, FDD layer416(or a policy executed by an integrated control engine or business rules engine) can shut-down systems or direct control activities around faulty devices or systems to reduce energy waste, extend equipment life, or ensure proper control response.

FDD layer416can be configured to store or access a variety of different system data stores (or data points for live data). FDD layer416can 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 subsystems428can generate temporal (i.e., time-series) data indicating the performance of BMS400and the various components thereof. The data generated by building subsystems428can 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 set-point. These processes can be examined by FDD layer416to expose when the system begins to degrade in performance and alert a user to repair the fault before it becomes more severe.

Ethernet Ring Topology Generation

The BMS, as described above, can have multiple individual components within the BMS. Example components may include control devices, such as field equipment controllers (FECs), advanced application field equipment controllers (FACs), network control engines (NCEs), input/output modules (IOMs), and variable air volume (VAV) modular assemblies. However, other control device types are contemplated. For example, the BMS may include multiple devices such as sensors, actuators, valves, beacons, switches, thermostats, etc. In some embodiments, some or many of these devices may be configured as or connected to a network and controlled through that network. For example, the network may be an Ethernet network arranged in a ring topology. The present disclosure describes a mechanism to dynamically and efficiently determine the topology of the devices within the ring, thereby allowing for the system configuration to be easily verified automatically. Further, the mechanism for determining the topology of the devices within the ring can allow for more efficient identification of a malfunctioning device within the Ethernet ring when a fault is detected.

Referring now toFIG.5, a block diagram illustrating a networked system500is shown. The system includes an Ethernet ring topology generator (RTG)502, a ring supervisor504, and a number of devices506-518. As described above, the devices506-518may be any type of devices within a BMS that are connected via an Ethernet connection. The RTG502may be a remote server, a personal computer, a laptop computer, or other device configured to operate as the topology generator. In one embodiment, the RTG502is a Metasys server from Johnson Controls, Inc. In some embodiments, the RTG502must be a device outside of an Ethernet ring in order to accurately generate the topology of the devices within the Ethernet ring. The RTG502is configured to transmit one or more commands to the devices506-518in the Ethernet ring via the ring supervisor504. The RTG502may further be configured to generate and manage one or more topology tables associated with an Ethernet ring, and which may be used to determine an order and configuration of the devices506-518arranged in an Ethernet ring520. In some examples, the RTG502may also store the topology information in lists, arrays or other data structures, as applicable. In one embodiment, to determine the topology of the devices506-518of the devices within the Ethernet ring520, the RTG502must determine the following information: the devices in the ring, the order of the devices in the ring relative to each other; and how the devices are connected to each other (i.e., which Ethernet ports connect two devices in the ring, or which Ethernet ports of a device connects the device to the ring supervisor504. The processes for determining the above information will be described in more detail below.

The ring supervisor504may be standard Ethernet switch configured to manage a number of Ethernet-based devices in ring topology. In one embodiment, the Ring supervisor504is configured to host a Dynamic Host Control Protocol (DHCP) server and a MRP ring manager. The ring supervisor504may have a number of Ethernet ports for communicating with one or more Ethernet devices or networks. In one embodiment, the ring supervisor504uses two ports, such as port A and port B to communicate with the devices506-518and generate an Ethernet ring. As stated above, the Ethernet ring520of system500may be configured as an MRP ring. However, the herein disclosed topology determination methods and systems are intended to be protocol agnostic, and could be used in various other Ethernet ring protocols, such as a spanning tree protocol (STP) rings, daisy chain configurations, and/or other Ethernet ring protocols. In an MRP ring, an MRP beacon frame may be transmitted to each of the devices506-518in the Ethernet ring520to inform the devices506-518that they are a member of an MRP ring. The devices506-518, upon receiving the MRP beacon flag, flag themselves as being a part of an MRP ring. In an MRP ring, one device in the ring (e.g. the ring supervisor504) manages the Ethernet ring520to prevent continuous/infinite looping of messages within the Ethernet ring520.

Each of the devices506-518may include a first port and a second port. For example, device A506is shown to include Port 1 and Port 2. One port may be designated as a receiving port and the other port may be a forwarding port. In one example, when the ring is closed (e.g. there is no break in the connectivity in the ring), the ring supervisor504may block one of the ports to prevent infinite looping within the ring and forwards all packets received outside the ring to the device on the ring. However, both Port 1 and Port 2 may be capable of sending and receiving data packets, as needed. For example, for device A506, Port 1 is shown as a receiving port, and port 2 is shown as a forwarding port. However, the ports (e.g. port 1 and port 2) may be interchanged between being a forwarding port and a receiving port based on which port on the ring supervisor504is being used as a forwarding port. For example, in the system500, if Port 4 of the ring supervisor504is used as the forwarding port of the ring supervisor504, then Port 2 would be the receiving port and Port 1 would be the forwarding port of device A506. In a typical ring topology, one port of the ring supervisor504is set as the forwarding port to prevent redundant messages from being provided to the Ethernet ring520.

Turning now toFIG.6, a data flow chart illustrating a process600for discovering the devices in an Ethernet ring is shown, according to some embodiments. The process600is described in reference to the system500described above. However, it is contemplated that the process600can be used with various other Ethernet networks, as described above. As stated above, before the topology of the devices506-518can be determined, the RTG502needs to discover the devices506-518that are participating in the Ethernet ring520. In some embodiments, the discovery process600includes discovering the devices506-518as well as the ring supervisor504. More specifically, the discovery process600determines which ports on the ring supervisor504are hosting the Ethernet ring520. In some embodiments, the RTG502can be pre-configured with basic information about the Ethernet ring520. For example, the RTG502may be configured with the IP address of the ring supervisor504hosting the Ethernet ring520, and the type of ring (MRP, STP, etc.) being used. This information can be used to determine which ring supervisor504commands need to be issued to obtain a status of the Ethernet ring520. Additionally, the RTG502may know the switch ports of the ring supervisor504used to operate the ring Ethernet520, and a subnetwork of the devices in the Ethernet ring520. In some embodiments, a user may provide this information to the RTG502. In other embodiments, the RTG may interrogate the Ring supervisor504to obtain the necessary information.

The RTG502first transmits a ring status query602to determine if the Ethernet ring520is open or closed. If the ring is closed, the RTG502determines that all devices506-518are reachable and broadcasts a device discovery broadcast message604. Upon receiving the device discovery broadcast message604, the devices506-518respond by transmitting a device discovery response606. The device discovery response606may include a device ID, and a device IP address.

Upon receiving a device discovery response606from each of the devices506-518, the RTG502may create a ring topology data structure and populate the data structure with the information within the received device discovery responses606. In one embodiment, the data structure is a Ring Topology Table, such as Table 1, shown below.

TABLE 1Ring Topology Table with Device Discovery Response DataRing Topology TableEthernet SupervisorPort to PreviousPort To NextRing OrderPort/Ring Device IDRing DeviceRing DeviceCountSupervisor Ring PortN/AN/ADevice CDevice FDevice BDevice GDevice DDevice ADevice ESupervisor Ring PortN/AN/A

After the devices506-518of the Ethernet ring are discovered, the RTG502initiates an Ethernet port orientation process700, as shown inFIG.7to orient the ports of the devices506-518relative to each other. In one embodiment, the RTG502orients each device's506-518ports relative to the ring supervisor's504forwarding ring port. In order to prevent infinite looping when the ring is closed, the ring supervisor504may block one of its ring ports (Port 3 or Port 4) such that data from outside the Ethernet ring520is always routed into the Ethernet ring520through the other ring port (the forwarding port). Therefore, all of the device506-518will receive messages on their data port which is closest to the ring supervisor's504forwarding port.

In one embodiment, the RTG502first transmits a ring status query702to the ring supervisor504to determine if the Ethernet ring520is open or closed. If the ring is open, the RTG502may abort the Ethernet port orientation process700. If the ring is closed, the RTG502may transmit a ring port status query704to the ring supervisor504to determine which port is currently configured as the forwarding port of the ring supervisor504, and therefore which port of the ring supervisor504is blocked. In one embodiment, the ring status query702and the ring port status query704may be combined into a single query. For purposes of this example, the forwarding port is determined to be Port 3, and the blocked port is determined to be Port 4.

The RTG502may then broadcast a ring port request message706to all of the devices506-518. The devices506-518may then respond back to the RTG502with a ring port response message708containing their Device ID, and the port on which they received the ring port request message (e.g. port 1 or port 2). In one example, messages from the RTG502will be received on the Ethernet port closest to the forwarding port of the ring supervisor504for each of the devices506-518where the Ethernet ring520is closed. The port receiving the ring port request message706therefore is either directly connected to the forwarding port of the ring supervisor504(port 3), or is connected to the previous device506-518in the ring relative to the forwarding port of the ring supervisor504(port 3). Therefore, the device's506-518other port is therefore connected to either the blocked port of the ring supervisor504(port 4) or to the next device506-518in the Ethernet ring520, according to some embodiments.

The RTG502may then update the Ring Topology table with the data received in the ring port response messages708received from the devices506-518. In one embodiment, the RTG502may populate the Port to Previous Ring Device with the Ethernet port (1 or 2) of each device506-518based on the data received in the ring port response message708. The Port to Previous Ring Device data points indicate which port of a given device506-518is closest to the ring supervisor's504forwarding port. The RTG502may also populate the Port to Next Ring Device with the Ethernet port (1 or 2) of each device506-518based on the data received in the ring port response message708. The Port to Next Ring Device data points indicate which port of a device506-518is closest to the Ethernet ring's520blocked port (port 4). An example updated Ring Topology Table is shown in Table 2 below.

TABLE 2Ring Topology Table with Device Port DataRing Topology TableEthernet SupervisorPort to PreviousPort To NextRing OrderPort/Ring Device IDRing DeviceRing DeviceCountSupervisor Ring PortN/A3N/ADevice C210Device F120Device B120Device G210Device D120Device A120Device E120Supervisor Ring Port4N/AN/A

Once the RTG502has determined the orientation of each of the devices'506-518ports relative to the ring supervisor504, the RTG502can determine an order of the devices in the ring relative to the ring supervisor's504forwarding port. Turning now toFIG.8, a data flow chart illustrating a process800for determining a position of devices in an Ethernet ring is shown, according to some embodiments. The RTG502first transmits a ring status query802to the ring supervisor504to determine if the Ethernet ring520is open or closed. If the Ethernet ring520is determined to be open, the RTG502aborts the process800. If the Ethernet ring520is determined to be closed, the RTG502then sends a port status change request message804to a first device506-518of the Ethernet ring520. In some embodiments, the RTG502may transmit the port status change request message804to the device which is listed first in the generated ring topology table. However, in other embodiments, the RTG502may transmit the port status change request message to a device based on other criteria.

In one embodiment, the port status change request message804includes a command to disable one ports of the device506-518receiving the message804. In one embodiment, the port status change request message804instructs the device506-518receiving the message804to disable the port associated with the port to next ring device parameter in the ring topology table for the associated device506-518. As shown inFIG.8, device C510may be the first device to receive the port status change request message804. In some embodiments, the device506-518currently receiving the port status change request message804is referred to as the reference device. After the device C510disables a port, the device C510may transmit a port status change request message806to the RTG502indicating that the port has been disabled. Upon receiving the port status change request message806, the RTG502again transmits a ring status query808to the ring supervisor504to verify that the ring is now open. Upon verifying that the ring is open, the RTG502broadcasts a ring port request message810to devices506-518via the forwarding port of the ring supervisor504. Each device506-518receiving the ring port request message810may transmit a ring port response message812to the RTG502.

Upon receiving the ring port response messages812, the RTG502first determines if the ring port response message812is from the reference device (e.g. the device with the currently disabled port). If the ring port response message812is from the reference device, the RTG502ignores the ring port response message812. For the ring port response messages812not from the reference device, the RTG502then determines if the ring port response message for each of the other non-reference devices506-518is received from the Ethernet port which matches the Port to Previous Ring Device parameter for each associated device in the ring topology table. If the ring port response message812is not from the reference device, and the Ethernet port from which the ring port response message812was received matches the port to previous ring device parameter within the ring topology table, the RTG502increments a ring order count parameter in the ring topology table for the associated device. As only the forwarding port of the ring supervisor504is active, the RTG502will only receive the ring port response messages from device506-518between the forwarding port of the ring supervisor504and the reference device. At this point the ring is open such that the ring supervisor504can send the ring port request message810over both its ring ports (e.g. port 1 and port 2). However, only the devices which receive the ring port request message810via the previously defined forwarding port (i.e., The Port to Previous Ring Device port) will have their Ring Order Count incremented. Thus, as in the above example where the device C is the initial reference device, after all of the ring port response messages812have been received, the ring order count parameters values within the ring topology chart will be as shown in Table 3, below.

TABLE 3Ring Topology Table with Initial Ring Order CountRing Topology TableEthernet SupervisorPort to PreviousPort To NextRing OrderPort/Ring Device IDRing DeviceRing DeviceCountSupervisor Ring PortN/A3N/ADevice C210Device F120Device B121Device G210Device D120Device A121Device E120Supervisor Ring Port4N/AN/A

Once the ring port response messages812have been received, the RTG502may transmit a port status change request814to the reference device, device C510. The port status change request814can instruct the reference device, device C510to re-enable its Ethernet port. The reference device, device C510, can then transmit a port status change response816to the RTG502indicating that the port has been re-enabled. The port status change response816may include a message ID indicating that the message is a port status change response, an Ethernet port that was updated, and a result bit associated with the updated Ethernet port (e.g. 1-port enable, 2-port disabled). Upon receiving the port status change response816, the RTG502may transmit a port status change request818to a subsequent device506-518in the ring that is different from the previous reference device. After receiving confirmation that the device's Ethernet port has transitioned back to enabled, the RTG502may perform another Query Ring Status to confirm that the ring is now closed, and prior to moving on to the next device with818. The RTG502may then repeat the above process for the new reference device, and continue until each of the previously discovered devices506-518have been designated as the reference device (e.g. had a port disabled). Upon completion of the process800, the ring topology table may include the following data as shown in Table 4 below, based on the system500.

TABLE 4Ring Topology Table Including Complete Ring Order Count DataRing Topology TableEthernet SupervisorPort to PreviousPort To NextRing OrderPort/Ring Device IDRing DeviceRing DeviceCountSupervisor Ring PortN/A3N/ADevice C214Device F121Device B125Device G210Device D123Device A126Device E122Supervisor Ring Port4N/AN/A

The RTG502may then order then devices506-518based on their respective ring order count. By ordering the devices506-518from highest ring order count to lowest ring order count, the devices506-518will be listed in the order they are installed in the ring in relation to the forwarding port of the ring supervisor504, as well as how the device506-518in the ring are connected to each other (e.g., the Port to Previous Ring Device for the first device in the ring topology table is connected to the ring manager forwarding port, the Port to Next Ring Device of the first device in the ring topology table is connected to the Port to Previous Ring Device of the second device in the ring topology table, and so on). For the system500ofFIG.5, the ordered ring topology table is shown below in Table 5.

TABLE 5Ordered Ring Topology TableRing Topology TableEthernet SupervisorPort to PreviousPort To NextRing OrderPort/Ring Device IDRing DeviceRing DeviceCountSupervisor Ring PortN/A3N/ADevice C214Device F121Device B125Device G210Device D123Device A126Device E122Supervisor Ring Port4N/AN/A

Turning now toFIG.9, a flow diagram illustrating a process900for determining a topology of an Ethernet ring is shown, according to some embodiments. The process900may be a combination of the processes600,700and800described above. In one embodiment, the process900operates at the application layer, allowing the topology of the Ethernet ring520to be determined by communicating directly with the devices in the Ethernet ring, rather than relying on messaging type specific to the ring protocol to provide the topology information. In some embodiments, an RTG, such as RTG502described above, may be responsible for performing the various steps of the process900. In one example, the RTG may interface with a user, such as via a graphical user interface (GUI), to allow a user to both configure the RTG, but also to present the user with a graphical representation of the generated ring topology, in some embodiments. In one embodiment, when the RTG is initialized or launched, the RTG will initially generate the topology of the configured Ethernet ring as described below. Further, the RTG may continue to monitor the status of the ring to determine if/when the topology needs to be re-generated. For example, the RTG may regenerate the ring topology whenever the ring status transitions from open to closed to account for the addition/deletion of devices to the Ethernet ring as well as any cabling changes within the Ethernet ring (e.g. if the cables going into a particular device's Ethernet ports were swapped.)

At process block902, all the devices within the Ethernet ring are discovered. In one embodiment, an RTG, such as RTG502may execute a process to discover all of the devices within the Ethernet ring. For example, the RTG may use a process such as process600described above to discover all the devices in the Ethernet ring. The RTG may also determine other information about the devices, such as IP addresses of the devices, device types, associated other devices, associated sub-networks, or the like.

At process block904, the RTG may determine a port configuration of the discovered devices. In some embodiments, the RTG may determine the port configurations using a process similar to process700described above. For example, the RTG may broadcast a ring port request to the devices on the Ethernet ring. In some embodiments, the RTG first ensures that one of the ports of an Ethernet ring supervisor associated with the Ethernet ring is disabled, ensuring that any message broadcasted by the RTG is only provided to the Ethernet ring via a single port. However, it should be understood that the step of disabling one of the ports of the Ethernet ring supervisor is optional and can be omitted in other embodiments. By determining the port configurations of the discovered devices, the RTG can determine a relationship of the Ethernet ports of the devices in regards to each other, and an Ethernet ring supervisor, such as ring supervisor504. The RTG may then populate a data structure with the individual devices within the Ethernet ring, as well as the relationships of their individual ports. For example, the RTG may populate the data structure with data such as the “port to previous ring device,” indicating which port the device received the broadcasted message from the RTG.

At process block906, the RTG may transmit an instruction to a first device within the Ethernet ring and instruct the first device to disable one of the Ethernet ports of the device. The device with the disabled port may be referred to as the reference device. The RTG may then determine if the Ethernet ring is open at process block908. In some embodiments, the RTG may verify that the Ethernet ring is open by querying the Ethernet ring supervisor, which can provide a status of the Ethernet ring (e.g. whether the Ethernet ring is open or closed). In other embodiments, the RTG may broadcast a message to the devices on the Ethernet ring and determine if a response is issued from all of the devices, or a portion of the devices, indicating whether the ring is open or closed.

Once the device determines that the Ethernet ring is open, the RTG broadcasts a ring port request to the devices in the Ethernet ring at process block910. The ring port request may include a message ID indicating that the message is a ring port request. The ring port request may be a standard request in Ethernet ring configurations. At process block912, the devices receiving the ring port request transmit a ring port response to the RTG. The ring port response may include a message ID, a device ID of the device transmitting the ring port response, a result and an Ethernet port message. The device ID may be a unique identifier for the device. For example, the device ID may be a BACnet OID, a logical name, a media access control (MAC) address, or some other existing ID. The result message may indicate whether the ring port response is successful or unsuccessful. Finally, the Ethernet port message may indicate on which port of the device the ring port request message was received. In one embodiment, the Ethernet port message may only be included in the ring port response where the result message indicates that the ring port response was successful. The RTG, having received the ring port responses from each of the devices receiving the ring port request increments a count associated with each device from which the ring port response is received. In one embodiment, the RTG may ignore the ring port response received from the reference device (e.g., the device with the disabled port).

Once all of the ring port responses have been received, the RTG enables the previously disabled port on the reference device at process block914. The RTG may further query the ring supervisor to confirm the ring is closed. The RTG then determines if all of the previously discovered devices within the Ethernet ring have had a port disabled (e.g., has each device been the reference device) at process block916. If the RTG determines that not all of the previous devices have had an Ethernet port disabled, the process900returns to process block906. If the RTG does determine that all of the devices have had their Ethernet ports disabled, the RTG may determine a topology of the Ethernet ring (e.g. determine the order of the discovered devices within the ring) at process block918. In one embodiment, the RTG may determine the topology of the devices in the Ethernet ring by ordering the devices based on the number of ring port responses received from each device. The RTG may then determine that the device with the highest number of associated port responses is the device closest to the forwarding port (e.g. active port) of the Ethernet ring supervisor). Therefore, the device with the lowest number of associated port responses is the device further away from the forwarding port of the Ethernet ring supervisory. Accordingly, the order of the devices, based on the number of received port responses, will correspond to the position of the device within the Ethernet ring with respect to the forwarding port of the Ethernet ring supervisor.

In an additional exemplary embodiment, the present disclosure describes a mechanism to dynamically and efficiently determine the topology of the devices within the ring, thereby allowing for the system configuration to be easily verified automatically, without requiring any interaction with the ring supervisor504. Rather, the RTG502is able to communicate directly with any of the devices504-518in order to determine the topology of the Ethernet ring520. In order to construct the topology of ring520, RTG502must determine at least the devices504-518which are in the ring520, the order of the devices504-518in the ring520relative to each other, and how the devices504-518are connected to each other (i.e., which Ethernet ports connect devices504-518in the ring520, or which Ethernet port connects a device504-518to the managed switch). In some embodiments, as described further below, RTG502may not be a separate application from the Ethernet ring520that resides outside of the Ethernet ring520, but instead functions with any Ethernet ring520where the associated RTG502makes a ring identifier and the open/closed status of the Ethernet ring520available to the devices504-518. Further, this additional mechanism for determining the topology of the devices within the ring can allow for more efficient identification of a malfunctioning device within the Ethernet ring when a fault is detected.

Turning now toFIG.10, a data flow chart illustrating an alternative process1000for discovering the devices in an Ethernet ring is shown, according to some embodiments. The process1000is described in reference to the system500described above, and defines an alternative mechanism for discovering the devices in an Ethernet ring that requires fewer communication between a ring topology generator application, ring devices, and a ring supervisor. However, it is contemplated that the process1000can be used with various other Ethernet networks, as described above. As stated above, before the topology of the devices504-518can be determined, the RTG502needs to discover the devices504-518that are participating in the Ethernet ring520. In some embodiments, the RTG502may be pre-configured with basic information about the Ethernet ring520. For example, the RTG502may be configured with the IP address of the ring supervisor504hosting the Ethernet ring520, and the type of ring (MRP, STP, etc.) being used. Additionally, the RTG502may know the switch ports of the ring supervisor504used to operate the ring520, and a subnetwork of the devices in the Ethernet ring520. In some embodiments, a user may provide this information to the RTG502. In other embodiments, the RTG may interrogate the Ring supervisor504to obtain the necessary information.

The device discovery process1000is initiated by the RTG502to discover the devices504-518in the Ethernet ring520. In some embodiments, the discovery process1000includes discovering the devices506-518. In order to successfully discover each and every one of the devices504-518within the ring520, the ring must be closed during the device discovery process1000. If ring520is not closed, each and every device506518may not respond to the process1000, as they may be unreachable if there are two or more breaks in the ring520. To start the device discovery process1000, the RTG502first transmits a device discovery request1002to discover the devices504-518within the ring. In some embodiments, the device discovery request1002may comprise a message ID, which may be set to 1 as this is the first message sent to determine ring topology, and a ring ID, which identifies the ring520. In other embodiments, the message ID may be set to any other value that will provide a unique message identifier to the receiver, while the specific value of the message ID is not important. If the ring520is an MRP ring, the ring ID is set to the MRP domain ID of the ring520for which the topology is being generated. In process1000, the device discovery request1002is broadcasted directly from the RTG502to the devices504-518, rather than to the ring supervisor504. Additionally, upon transmitting the device discovery request1002, the RTG502initiates a device discovery timer1004. The device discovery timer1004sets a time limit for the devices504-518to respond to the device discovery request1002. In some embodiments, the time limit is predetermined and stored within the RTG502. In other embodiments, the time limit may be updated by a based on the ring for which the topology is being generated. The time limit sets a period of time for which the available devices504-518may respond to the device discovery request1002.

Upon receiving the device discovery request1002, each of the devices504-518receives the device ID of the Ethernet ring520for which the topology is being generated. Each of the available devices504-518within the ring520responds to the device discovery request1002by transmitting a device discovery response1006. In some embodiments, the devices504-518may only transmit a device discovery response1006if their local ring ID for ring520matches the device ID included in the device discovery request1002. In some embodiments, the device discovery response1006comprises a message ID, set to 2 as this is the second message, a ring ID to identify ring520, a device ID, and a ring state, set to either 0 to indicate that the ring520is open, or set to 1 to indicate that the ring is closed. The device ID may comprise a unique identifier for the specific device, such as BACnet object identifiers, a logical name, or another pre-existing ID of the device. In some embodiments, the RTG502will wait for device discovery responses1006from each of the devices504-518, from the start device discovery timer1004until the device discovery timer expires1008.

Upon receiving a device discovery response1006from each of the available devices504-518, or upon the device discovery timer expiration1006, the RTG502may create a ring members data structure and populate the data structure with the information within the received device discovery responses1006. In one embodiment, the data structure is a Ring Members List, such as Table 6, shown below.

TABLE 6Ring Members List after Device Discovery ProcedureRing Members ListPort To PreviousPort To NextRing Device IDIP AddressRing DeviceRing DeviceDevice C192.168.10.4——Device F192.168.10.7——Device B192.168.10.1——Device G192.168.10.6——Ring Supervisor192.168.10.10——Device D192.168.10.3——Device A192.168.10.2——Device E192.168.10.5——

When the device discovery timer expires at1008, the RTG502ends the device discovery process1000and determines if the ring520is in an open or closed state based on the responses from the devices504-518within the ring520. The device discovery responses1006comprise an indication of if the device is in an open or closed state. If the ring520is open, the RTG502will initiate the ring state query process1200or the ring state notification process1300, as described in greater detail below. In some embodiments, when the state of ring520transitions to closed, the RTG502may clear the Ring Member's List and re-initiate device discovery process1000in order to rediscover all of the devices504-518within the ring520.

After the devices504-518of the Ethernet ring are discovered, and it has been determined that the MRP ring state of the devices504-518are all closed, the RTG502initiates an Ethernet port orientation process1100, as shown inFIG.11, to orient the ports of the devices504-518relative to each other. The Ethernet port orientation process1100is initiated by a broadcast from the RTG502to the devices504-518. In one embodiment, the process1100determines the order of the devices504-518and the orientation of the ports relative to the adjacent ring devices (i.e., which ports of the device are connected to each adjacent device.) In some embodiments, the Ethernet port orientation process1100relies on the order in which the devices504-518respond to the RTG502during device discovery process1000, which is also the order of the devices504-518as shown in the Ring Members List of Table 6. As device C510is the first device in the list, device C510will be the first device to be tested and oriented by the Ethernet port orientation process1100.

The Ethernet port orientation process1100is initiated by the RTG broadcasting a ring ordering start message1102to each of the devices504-518. In some embodiments, the ring ordering start message1102may comprise a message ID, which may be set to 3 to indicate it is the third message, a ring ID acting as an identifier for the ring520, and an indication of the initial device under test, such as the device ID of which device506-518is to initiate the process. The first device within the Ring Member's List, for example device C510as shown inFIG.11and Table 6, may be the initial device under test. After testing the initial device, the Ethernet port orientation process1100may test each additional device, as determined by the order in the Ring Member's List. Additionally, upon transmitting the ring ordering start message1102, the RTG502initiates a ring device information timer1104. The ring device information timer1104sets a time limit for the devices504-518to respond to the ring ordering start message1102. In some embodiments, the time limit is predetermined and stored within the RTG502. In other embodiments, the time limit may be updated by a based on the ring for which the orientation is being generated. The time limit sets a period of time for which the currently tested device504-518may respond to the ring ordering start message1102.

Upon receiving the ring ordering start message1102, each of the devices504-518record that the ring ordering and Ethernet port orientation process1100is in progress. The ring ordering start message1102may also inform the devices504-518that the Ethernet port orientation process1100has started, such that if one of their links goes OOS, the ring ordering start message1102may indicate that they are now the device under test. The ring ordering start message1102indicates the order of the devices to be tested. Upon receipt of the ring ordering start message1102, the first device under test (device C510) disables one of its Ethernet ports (1 or 2), as determined by a command to disable the port included within the ring ordering start message1102. In some embodiments, the lowest numbered Ethernet port (port 1), is disabled first. Referring now toFIG.12, a block diagram illustrating the networked system500with a disabled port 1 on device C510is shown. As seen inFIG.12, the link between port 1 of device C510and port 1 of device D512is terminated due to the disabled port. After the device C510disables a port, device C510waits for a notification from the ring supervisor504that indicates that the ring is in an open state, due to the port being disabled. In some embodiments, the ring520is an MRP ring, the change in the state of the ring may be provided by an MRP test frame. Once device C510has been notified by the ring supervisor504that the ring520is in an open state, device C510transmits a ring device information message1108back to RTG502.

Ring device information message1108is sent from device C510, or whichever device506-518is currently being tested, back to the RTG502to identify the device C510location and orientation within the ring520. In some embodiments, ring device information message1108comprises a message ID, which may be set to 4 to indicate that it is the fourth message, a port to previous ring device, and a port to next device. The port to previous ring device indicates which Ethernet port of device C510is connected to the previous device in the ring520. The port to next ring device indicates which Ethernet port of device C510is connected to the next device in the ring520. The determination of port to previous rind device and port to next ring device is described in further detail below. Device C510autonomously re-enables the disabled port after sending the ring device information message1108. Additionally, there may be a restart of ring device information timer1110after RTG502has received ring device information message1108from device C510. A restart of ring device information timer1110may occur after each tested device has sent a ring device information message1108to RTG502.

Additionally, upon receiving the ring device information message1108from device C510, the RTG502may update the data structure with the information received from the ring device information message1108. For examples, the port to previous ring device may be added to Ring Members List in the “Port to Previous Ring Device” column, and the port to next ring device may be added to Ring Members List in the “Port to Next Ring Device” column. In one embodiment, the updated Ring Members List, is shown as Table 7 below.

TABLE 7Ring Members List with Initial Ring Information Based on Initial DeviceRing Members ListPort To PreviousPort To NextRing Device IDIP AddressRing DeviceRing DeviceDevice C192.168.10.421Device F192.168.10.7——Device B192.168.10.1——Device G192.168.10.6——Ring Supervisor192.168.10.10——Device D192.168.10.3——Device A192.168.10.2——Device E192.168.10.5——

When device C510has disabled port 1, the second device in the Ring Member's List (in this case, device D512) detects the link terminated by its Ethernet port 1, as port 1 of device C510is connected to port 1 of device D512. The terminated link can be seen inFIG.12. Link termination1106of the Ethernet port 1 may be detected by device D512. In some embodiments, the link between port 1 of device D512and port 1 of device C510may correspond to a physical link layer (layer 1) as well as a data link layer (layer 2), which may handle the movement of data between adjacent nodes in the ring520. Upon detecting the terminated link, device D512may automatically determine that it is the next device to be tested. Device D512may then locally identify Ethernet port 1 as the Port to Previous Ring Device, which may later by transmitted to RTG502in order to update Ring Member's List.

After the second device, device D512, has detected the link and identified that it is the next device under test, device D512waits for the ring520to transition back to the closed state. This transition occurs when device C510re-enables port 1, and the link is restored between port 1 of device C510and port 1 of device D512. Device D512identifies that the link has been restored1112and identifies that the ring is in the closed state, and device D512is now under test. Upon transitioning back to the closed state, the next device under test (device D512) disables one of its Ethernet ports. The Ethernet port which has not already had a link terminated is disabled. As the link between port 1 of device D512was already terminated during testing of device C510, device D512will proceed with disabling port 2. As seen inFIG.13, disabling port 2 of device D512terminates the link between port 2 of device D512and port 1 of device E514. After device D512disables a port, device D512waits for a notification from ring supervisor504that the ring is in an open state, due to the port being disabled. Once device D512has been notified by the RTG502that the ring520is in an open state, device D512transmits a ring device information message1108back to RTG502.

Ring device information message1108is sent from device D512back to the RTG502to identify the device D512location and orientation within the ring520. Similarly to ring device information message1108sent from device C510, ring device information message1108comprises a message ID, which may still be set to 4 to indicate this is the fourth message in the testing procedure, a port to previous ring device, and a port to next device. Device D512autonomously re-enables the disabled port after sending the ring device information message1108. Additionally, RTG502may restart the ring device information timer1110after receipt of ring device information message1108from device D512.

Additionally, upon receiving the ring device information message1108from device D512, the RTG502may update the data structure with the information received from the ring device information message1108. For example, the port to previous ring device may be added to Ring Members List in the “Port to Previous Ring Device” column, and the port to next ring device may be added to Ring Members List in the “Port to Next Ring Device” column. The port to previous ring device may be determined by the port which had a link terminated during testing of device C510. The port to next ring device may be determined to be the port that is disabled during testing of device D512. In one embodiment, the updated Ring Members List, is shown in Table 8 below.

TABLE 8Ring Members List with Ring Information Based on Second DeviceRing Members ListPort To PreviousPort To NextRing Device IDIP AddressRing DeviceRing DeviceDevice C192.168.10.421Device D192.168.10.712Device F192.168.10.7——Device B192.168.10.1——Device G192.168.10.6——Ring Supervisor192.168.10.10——Device A192.168.10.2——Device E192.168.10.5——

When device D512has disabled port 2, the third device in the Ring Member's List (in this case, device E514) detects the link terminated by its Ethernet port 1, as port 2 of device D512is connected to port 1 of device E514. This terminated link can be seen inFIG.13. Link termination1106of the Ethernet port 1 may be detected by device E514. In some embodiments, the link between port 1 of device E514and port 2 of device D512may correspond to a physical link layer (layer 1) as well as to a data link layer (layer 2), which may handle the movement of data between adjacent nodes in the ring520. Upon detecting the terminated link, device E514may automatically identify that it is the next device to be tested. Device E514may then locally identify Ethernet port 1 as the Port to Previous Ring Device, which may later by transmitted to RTG502in order to update Ring Member's List.

Process1100continues for each of the devices504-518until each device506-518within ring520has been tested, i.e. has had a port disabled. Upon receiving the ring device information message1108from each device506-518, the RTG502may update the data structure with the information received from the ring device information message1108. In some embodiments, process1100continues until device C510detects the link terminated by its port 2 and port 2 of device B508. As device C510has already sent the RTG502a ring device information message1008earlier in the process1100, device C510takes no action, causing the expiration of ring device information timer1114. Upon expiration of ring device information timer1114, RTG502broadcasts a ring ordering complete message1116to the devices504-518within ring520, indicating that the ring ordering and Ethernet port orientation process1100is complete. In some embodiments, RTG502checks to see if all entries in the Ring Member's List have been populated. If all entries have not been populated, RTG502may clear the Ring Member's List and re-initiate process1100. In other embodiments, if the RTG502has found that not all devices have responded with a ring device information message1108, the RTG502may imitate a second port orientation procedure, starting with the same device such as device C510, but disable the alternative port of the device, thus allowing the process to discover devices504-518which may be on the other side of device C510.

Upon receipt of the ring ordering complete message1116, all of the devices504-518may record that the Ethernet orientation process1100is complete, such that a change in the state of one of their Ethernet links will not trigger the Ethernet orientation process1100behavior in the device. In some embodiments, ring ordering complement message1116may comprise a message ID, which may be set to 5 to indicate that it is the fifth message, and a ring ID acting as an identifier for the ring520. After successful completion of the process1100, the data structure will be fully populated. In one embodiment, the completed Ring Members List is shown as Table 9 below.

TABLE 9Ring Members List with Full Ring OrderingRing Members ListPort To PreviousPort To NextRing Device IDIP AddressRing DeviceRing DeviceDevice C192.168.10.421Device D192.168.10.312Device E192.168.10.512Device F192.168.10.712Device G192.168.10.621Ring Supervisor192.168.10.1034Device A192.168.10.212Device B192.168.10.112

In some embodiments, the topology of Ethernet ring520is regenerated each time the Ethernet ring520transitions from open to close, or vice versa. In some embodiments, the RTG502may periodically query one of the devices504-518within the Ethernet ring520in order to determine the ring state. An exemplary embodiment of the ring state query procedure is shown inFIG.12. In other embodiments, the RTG502may subscribe to ring state change notifications from one or more of the devices504-518within the Ethernet ring520, such that the devices504-518provide the RTG502with an identification of when the Ethernet ring520has changed states. An exemplary embodiment of a ring state notification procedure, where the devices504-518provide an indication of a ring state change to the RTG502, as shown inFIG.15.

Turning now toFIG.14, a data flow chart illustrating a ring state query process1400for determining the state of the devices504-518within an Ethernet ring is shown, according to some embodiments. As stated above, the ring state query process1400is used to query the device506-518of the Ethernet ring520for the status of the ring520. In some embodiments, the RTG502may periodically query one of the devices504-518to determine the status of the ring520. The RTG502first transmits a ring state request1402to the devices504-518. In some embodiments, the ring state request1402may comprise a message ID, which may be set to 6 to indicate that it is the sixth message, and a ring ID acting as an identifier for the ring520. In some embodiments, the RTG502will transmit the ring state request1402to a particular device, for example to device C510as shown inFIG.14. In other embodiments, the RTG502will transmit the ring state request1402to a different singular device, or to multiple devices504-518. The ring state request1402requests the current ring state of the ring520. Upon transmitting the ring state request1402, the RTG502initiates a ring state response timer1404. The ring state response timer1404sets a time limit for the device506-518, which have received the ring state request1402, to respond to the ring state request1402, via a ring state response1406.

Upon receipt of the ring state request1402at device C510, device C510may respond with a ring state response1406. In some embodiments, the ring state response1406may comprise a message ID, which may be set to 7 to indicate that it is the seventh message, a ring ID acting as an identifier for the ring520, and a state of the ring520. The ring state may be set to either 0, to indicate the ring520is open, or to 1, to indicate that the ring520is closed. If the ring520is an MRP ring, the ring state is set based on the MRP ring state reported in the most recently received MRP test message. Once the RTG502receives the ring state response1406, the ring state response timer is cancelled1408. If, however, a ring state response timer1408has not been received by expiration of the ring state response timer, the RTG may initiate a ring state interval timer1410, and the RTG502may repeat the ring state query process1400. The process1400may be repeated continuously, based on the ring state interval timer1410, until a ring state response1406has been received at the RTG502. Process1400provides a method for the RTG to periodically query the ring520in order to determine if the ring state has changed.

Referring now toFIG.15, an exemplary embodiment of a ring state notification process1500, where the devices504-518provide an indication of a ring state change to the RTG502is shown. In contrast to process1400, process1500provides a mechanism for RTG502to be notified as soon as the ring state changes, rather than periodically querying the devices504-518. Ring state notification process1500allows the RTG502to request to be notified when the state of ring520changes, e.g., transitions from open to closed or vice-versa. In some embodiments, process1500notifies RTG502immediately upon the change of state of ring520.

Process1500is initiated by RTG502broadcasting a ring state notification request1502to the devices504-518. In some embodiments, the ring state notification request1502may comprise a message ID, which may be set to 8 to indicate that it is the eight message, and a ring ID acting as an identifier for the ring520. In some embodiments, the RTG502will transmit the ring state notification request1502to a particular device, for example to device C510as shown inFIG.15. In other embodiments, the RTG502will transmit the ring state notification request1502to multiple device506-518. It may be beneficial to transmit the ring state notification request1502to multiple devices504-518, as RTG502is unaware of which devices504-518may be offline and are unreachable. Upon transmitting the ring state notification request1502, the RTG502initiates a ring state notification confirmation timer1504. The ring state notification confirmation timer1504sets a time limit for the device506-518, which have received the ring state notification request1502to respond to the ring state notification request1502via a ring state notification confirmation1506.

Upon reception of the ring state notification request1502, the device506-518which received the ring state notification request1502, in this case device C510, stores the address of the RTG502. Device C510also responds with a ring state notification confirmation1506. Sending the ring state notification confirmation1506indicates that device C510will indicate to the RTG502whenever there is a change of state of the ring520. In some embodiments, ring state notification confirmation1506may comprise a message ID, which may be set to 9 to indicate that it is the ninth message, and a ring ID acting as an identifier for the ring520. The ring state notification confirmation1506is sent by the device C510, or any of the devices504-518which received the ring state notification request1502, in order to notify the RTG502that the RTG502has been successfully registered to receive ring state change notifications from device C510. Upon reception of the ring state notification confirmation1506by the RTG502, the RTG502may cancel the ring state notification confirmation timer1508. If the ring state notification confirmation1506has not been received by an expiration of the ring state notification confirmation timer, it may be assumed that the device C510is unreachable, and thus ring520is in an open state.

When the state of ring520changes, device C510will notify RTG502of the change in state. Device C510sends a ring state change notification1510to RTG502in order to indicate the change of state. In some embodiments, ring state change notification1510may comprise a message ID, which may be set to 10 to indicate that it is the tenth message, a ring ID acting as an identifier for the ring520, and a ring state, set to either 0 or 1. If the ring520is an Ethernet ring using MRP, the ring state is based on the MRP ring state reported in the most recently received MRP test message. Anytime the state of ring520changes, device C510will send another ring state change notification1510to RTG502. Thus, RTG502is notified of changes in ring state as soon as they occur, rather than having to periodically query the devices504-518.

If it is decided that the RTG502no longer wishes to receive ring state change notifications1510, the RTG502may broadcast a ring state cancellation request1512. The ring state cancellation request1512may be broadcasted to any of the devices504-518currently providing state changes of the ring520to the RTG502. This may be any of the devices504-518which received the ring state notification request1502and responded with a ring state notification confirmation1506. In some embodiments, the ring state cancellation request1512may comprise a message ID, which may be set to 11 to indicate that it is the eleventh message, and a ring ID acting as an identifier for the ring520. Upon transmitting the ring state cancellation request1512, the RTG502initiates a ring state cancellation confirmation timer1514. The ring state cancellation confirmation timer sets a time limit for the devices504-518, which have received the ring state cancellation request1512to respond to the ring state cancellation request1512via a ring state cancellation confirmation1516.

Upon receipt of the ring state cancellation request1512at device C510, or whichever devices504-518have received the request1512, device C510is instructed to stop sending ring state change notifications1510. Device C510clears the address of RTG502so that ring state change notifications1510can no longer be sent. Additionally, upon receipt of the ring state cancellation request1512, device C510responds by broadcasting a ring state cancellation confirmation1516to RTG502. In some embodiments, ring state cancellation confirmation1516may comprise a message ID, which may be set to 12 to indicate that it is the twelfth message, and a ring ID acting as an identifier for the ring520. The ring state cancellation confirmation1516is sent by the device C510, or any of the devices504-518which received the ring state cancellation request1512, in order to notify the RTG502that the ring state cancellation request1512has been received and that ring state change notifications1510will no longer be sent from that particular device506-518to the RTG502. Once the RTG502receives the ring state cancellation confirmation1516, the ring state cancellation confirmation timer is cancelled1518. If, however, the ring state cancellation confirmation1516has not been received by the RTG502by the time the ring state cancellation confirmation timer expires, an additional ring state cancellation request1512may be sent by the RTG502. The ring state cancellation request1512may be periodically sent by the RTG502until a ring state cancellation confirmation1516is received by the RTG502.

Turning now toFIG.16, a flow diagram illustrating a process1600for determining a topology of an Ethernet ring is shown, according to some embodiments. The process1600may be a combination of the processes1000,1100,1400, and1500described above. In one embodiments, the process1600operates at the application layer, allowing the topology of the Ethernet ring520to be determined by communicating directly with the devices in the ring, rather than relying on messaging type specific to the ring protocol to provide the topology information. In some embodiments, an RTG, such as RTG502described above, may be responsible for performing the various steps of the process1600. In one example, the RTG may interface with a user, such as via a graphical user interface (GUI), to allow a user to both configure the RTG and to present the user with a graphical representation of the generated ring topology, in some embodiments. In one embodiment, when the RTG is initialized or launched, the RTG will initially generate the topology of the configured Ethernet ring as described below. Further, the RTG may continue to monitor the status of the ring to determine if/when the topology needs to be re-generated. For example, the RTG may regenerate the ring topology whenever the ring status transitions from open to closed to account for the addition/deletion of devices to the Ethernet ring as well as any cabling changes within the Ethernet ring (e.g. if the cables going into a particular device's Ethernet ports were swapped.)

At process block1602, all the devices within the Ethernet ring or a daisy chain are determined. In one embodiment, an RTG, such as RTG502may execute a process to discover all of the devices within the Ethernet ring. For example, the RTG may use a process such as process900described above to discover all the devices in the Ethernet ring. The RTG may also determine other information about the devices, such as IP addresses of the devices, device types, associated other devices, associated sub-networks, or the like.

At process block1604, the RTG transmits a ring order start message to the devices within the Ethernet ring in order to identify that a ring ordering procedure is occurring. The ring order start message may comprise an indication of which device will be the first device under test, based on the devices discovered at process block1602.

At process block1606, the RTG transmits an instruction to a device within the Ethernet ring and instructs the device to disable one of the Ethernet ports of the device. The first device to be instructed to disable the Ethernet port may be the first device discovered while discovering the device in process block1602, and may be indicated by the ring order start message sent at process block1604. The ring devices may then determine if the Ethernet ring is open at process block1608, indicating that a link is down between the device with the disabled port and its neighboring device. In some embodiments, the RTG may initiate a timer to wait for a ring device information message from one of the devices in the ring which will indicate whether or not the ring is open.

Once the device determines that the Ethernet ring is open, the device sends a ring device information to the RTG at process block1610. In some embodiments, the device may be sent as a unicast message to the RTG. The ring device information may include a message ID indicating that the message is a ring device information message. The ring device information message identifies which port has been disabled on the device, which the RTG then stores.

After broadcasting the ring device information, the device may re-enable the device forwarding port at process block1612. The RTG then determines if all of the previously discovered devices within the Ethernet ring have had a port disabled at process block1616. If the RTG determines that not all of the previous devices have had an Ethernet port disabled, the process1600returns to process block1606, and process block1606-1612are repeated for each discovered device. If the RTG does determine that all of the devices have had their Ethernet ports disabled, the RTG may determine a topology of the Ethernet ring (e.g. determine the order of the discovered devices within the ring) at process block1616. In one embodiment, the RTG may determine the topology of the devices in the Ethernet ring by ordering the devices based on the order of which the Ethernet ports are disabled on the discovered devices.

In some embodiments, the RTG may utilize the generated topology to be able to identify the location of one or more breaks in an Ethernet ring. For example, whenever a ring device's Ethernet port goes out of service (OOS), the device could send a message to the RTG reporting the OOS port. The RTG could then map the port to the current ring topology and mark the port to indicate the OOS status of the port. In other embodiments, failure or break events should be generated in pairs (i.e., if one end of a connection between two devices within the Ethernet ring goes OOS, then the other should as well, such that the RTG should mark both ends of the connection OOS. If another break in the ring is detected, the connectivity to one or more devices in the ring will be lost. Thus, it is important to make the user aware of the first break within the ring before the second break occurs, as this can prevent the loss of connectivity to multiple devices within the ring. If the second break does occur, the impacted devices can be determined based on the most recently determined topology of the ring. The RTG could determine the devices which have no connectivity based on the most recent ring topology and indicate to a user which devices have lost connection. In some embodiments, the topology of the ring may be displayed graphically, such as via a graphical user interface (GUI) of a webserver in order to give a user a clear and concise view of the status of the ring and the devices within the ring. Whenever a ring device's Ethernet port goes OOS, this may be visually represented on the GUI in order to identify to a user which devices may be affected.

In some embodiments, upon a change in status of an Ethernet port of a ring device, the device may report the new status of the Ethernet port to the RTG. In some embodiments, this status may be reported using process1500. In the case of a single break in the ring, two devices should report a change in status of one of their Ethernet ports, as two devices will be affected by a broken link. As seen inFIG.12, both device C510and device D512would report a change in the status of the link terminated between port 1 of device C510and port 1 of device D512. Thus, the RTG can easily identify where the broken link is and which ports have been affected. In the case of a failure of a device, the Ethernet ports on the devices on both sides of the failed device should report a change in their status. Based on the current topology of the ring, the RTG can determine which device (or devices) are not reachable based on the Ethernet ports whose links are determined to be down. For example, as seen inFIG.17, when device D512fails, both device C and device E would report a change in status of the link which was connected to device D512, as they are on either side of device D512.

In the case of two breaks within the ring, such as shown inFIG.18, the devices on either side of both breaks would report a change in the status of their links facing the break. As shown inFIG.18, a broken link between both device F516and device G518as well as between device D512and device C510. Thus, device D512, device E514, and device F516are all not reachable. The RTG is able to determine which devices are not reachable based on the current topology of the ring and which links are reported as being down. Additionally, repairs to the breaks within the ring may also be reflected in the topology of the ring. Every time a change in link status from down to up is received, the RTG may reassess the connectivity of the devices in the ring as well as the connections between them. If the failed devices are restored, but there is still a break in a link between them, the RTG would determine that all devices are reachable, but that the ring is still open due to the broken link. As seen inFIG.19, once device D512comes back into service, the link between device C510and device D512is repaired. Thus, devices D512, E514, and F516are all reachable, even though there is still a broken link between device G518and device F516, thus the ring is still open.

Advantageously, the systems and methods disclosed herein provide a simplified method for determining topology of a ring. The methods require significantly less messaging between the RTG and the devices within the ring in order to generate the topology of the ring without requiring modification of the RTG protocol itself. This reduction in messaging speeds up the time it takes to generate the ring topology, as well as reduces the potential for a lost message which could cause the ring topology generation process to fail. Additionally, these methods do not require any special interaction between the RTG and the ring manager. The RTG application interfaces with the ring devices in the same way regardless of whether the ring device is a ring client or a ring manager, further simplifying the implementation. Additionally, these methods do not require the RTG application to reside outside the ring for which it is determining the topology. Rather, the methods are application to any Ethernet ring where the associated RTG makes a ring identifier and the open/closed status of the ring available to the ring device. Thus, the present disclosure is a portable, lightweight solution that can be applied to Ethernet rings managed by various ring management protocols.

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. 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.