Building network performance based on device failure
By sending DER and error PDU messages in the building automation controller, faulty devices can be quickly identified and handled, solving the problem of communication latency in the building network and improving network performance and response speed.
Patent Information
- Application Number
- CN202580026261.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2024-04-04
- Filing Date
- 2025-03-18
- Publication Date
- 2026-11-03
AI Technical Summary
In building networks, communication delays and performance degradation caused by equipment failures are difficult to quickly identify and handle using existing technologies.
Building automation controllers detect equipment failures by sending Data Expectation to Reply (DER) messages and send error PDU messages when they determine that the equipment is not communicating, so that advanced applications can handle the failures in a timely manner.
It improves the responsiveness of building networks, reduces communication latency, ensures that advanced applications can quickly identify and handle faulty devices, and optimizes network performance.
Smart Images

Figure CN123036805A_ABST
Abstract
Description
Technical Field
[0001] This disclosure generally relates to building automation systems for controlling equipment within buildings, such as HVAC equipment, louver actuators, and lighting actuators. Background Technology
[0002] Building management systems encompass a variety of systems that help monitor and control all aspects of building operations. These include security systems, fire safety systems, lighting systems, and heating, ventilation, and air conditioning (“HVAC”) systems. Many building systems utilize standard communication protocols, such as Master-Slave / Token Passing (“MSTP”), to allow devices to communicate with each other over building networks, such as Building Automation and Control Networks (“BACnet”). In some cases, whether due to power outages, disconnected communication media, or other malfunctions, the communication protocols of building networks can take considerable time to identify faulty network devices. Such time delays in determining whether devices are communicating correctly can worsen exponentially for large building networks due to timeouts in building equipment configuration. Summary of the Invention
[0003] One aspect is a method for optimizing building network performance based on device failure. In response to recognizing a data request from an advanced application of the building automation controller, the building automation controller transmits a Data Expectation to Reply (DER) message to the field device. The network driver of the building automation controller determines that the field device sending the DER message is not communicating. In response to determining that the field device is not communicating, the network driver transmits an error PDU message to the advanced application.
[0004] Another aspect is a system for optimizing building network performance based on device failure, comprising a building automation controller, which includes an advanced application and a network driver. In response to recognizing a data request from the building automation controller's advanced application, the building automation controller transmits a Data Expectation to Reply (DER) message to the field device. The building automation controller's network driver determines that the field device sending the DER message is not communicating and, in response to determining that the field device is not communicating, transmits an error PDU message to the building automation controller's advanced application.
[0005] Another aspect is a non-transient computer-readable medium comprising executable instructions that, when executed, cause at least one processor of the building automation controller to optimize building network performance based on device failures. In response to recognizing a data request from an advanced application of the building automation controller, a Data Expectation to Reply (DER) message is transmitted to the field device. The network driver determines that the field device sending the DER message is not communicating. In response to determining that the field device is not communicating, the network driver transmits an error PDU message to the advanced application.
[0006] The foregoing has provided a fairly broad overview of the technical features of this disclosure to enable those skilled in the art to better understand the following detailed description. Other features and advantages of this disclosure that form the subject matter of the claims will be described below. Those skilled in the art will recognize that they can readily utilize the disclosed concepts and specific embodiments as a basis to modify or design other structures for achieving the same purposes of this disclosure. Those skilled in the art will also recognize that such equivalent constructions do not depart from the spirit and scope of the broadest form of this disclosure.
[0007] Furthermore, before proceeding with the detailed description below, it should be understood that various definitions of certain words and phrases are provided throughout this patent document, and those skilled in the art will understand that such definitions apply in many (if not most) cases to both prior and future uses of these defined words and phrases. While some terms may cover multiple implementations, the appended claims may expressly limit these terms to specific implementations. Attached Figure Description
[0008] Figure 1 A simplified diagram of a building automation system is shown.
[0009] Figure 2 A block diagram of a building automation controller is shown in an example implementation that can optimize building network performance based on equipment failures.
[0010] Figure 3 shows a timing diagram, which represents Figure 2 The state machine operates in an example implementation that can employ the techniques described in this article.
[0011] Figure 4 shows the timing diagram, which represents Figure 2 Another operation of the state machine in an example implementation that can employ the techniques described in this article.
[0012] Figure 5 It shows Figure 1 A block diagram of a data processing system, in which one implementation method can be achieved. Detailed Implementation
[0013] Various techniques relating to this disclosure will now be described with reference to the accompanying drawings, which relate to systems and methods for optimizing the network performance of building networks by facilitating notification of faulty network devices, wherein the same reference numerals denote the same elements throughout. The drawings discussed below, as well as the various embodiments used in this patent document to describe the principles of this disclosure, are merely illustrative and should not be construed as limiting the scope of this disclosure in any way. Those skilled in the art will understand that the principles of this disclosure can be implemented in any suitably arranged device. It should be understood that functions described as being performed by certain system components can be performed by multiple elements. Similarly, for example, elements can be configured to perform functions described as being performed by multiple elements. Numerous innovative teachings of this application will be described with reference to exemplary, non-limiting embodiments.
[0014] This system provides simulated error messages, or error PDUs, so that remote applications can be aware of equipment failures. Existing systems provide messages for transmitting coded building automation data between devices, but they do not provide remote applications with information indicating that a requested message was not received from another device. By introducing simulated error messages, applications can learn about failures much earlier than ever before.
[0015] refer to Figure 1 An example network topology of a building automation system 100 is illustrated. System 100 includes one or more network connections or a main bus for connecting elements to a management-level network (“MLN”) of system 100. In one embodiment, example system 100 may include one or more management-level devices or management workstations, such as management workstation 102, access controllers, or remote access controllers connected via wired or wireless networks, which allow setting and / or changing various controls of the system. Management workstation 102 may also be a portable management workstation connected via a wired or wireless link to a single automation-level or field-level device of system 100. While a brief description of system 100 is provided below, it should be understood that the system described herein is merely a simplified form or example of a configuration of the system. System 100 can be implemented in any other suitable manner without departing from the scope of this disclosure. The management workstation is configured to provide overall control and monitoring of the automation devices, field devices, and other devices of system 100.
[0016] for Figure 1In the illustrated implementation, system 100 provides connectivity to one or more devices and / or subsystems for various building parameters based on one or more communication protocols. While not mandatory, examples of subsystems include, but are not limited to, environmental / comfort subsystems, and / or other subsystems such as security subsystems, fire safety subsystems, etc. Each subsystem can include various types of building automation controllers and field devices for monitoring and controlling areas within a building or a group of buildings. These building automation controllers and field devices can communicate via one or more communication protocols, such as BACnet, KNX, LonWorks, Modbus, etc.
[0017] Building automation system 100 may include a management workstation 102 on a communication network 104 (such as a BACnet (IP Ethernet) network), which communicates with field devices 106 on a building network 108, such as BACnet MSTP devices on an MSTP network (RS485). Communication between building network 108 and the communication network may be facilitated by network devices (such as building automation controller 110). Examples of building automation controllers include, but are not limited to, BACnet IP / MSTP routers or MSTP room controllers, such as the Siemens DXR2.M room automation station provided by Siemens Switzerland GmbH in Zug, Switzerland.
[0018] The building automation controller 110 may include firmware that implements network stacks 112-118, such as the BACnet stack, to provide native interfaces to embedded devices and applications. The network stack may include an application layer 112, a network layer 114, a data link layer 116, and a physical layer 118. The physical layer 118 provides raw data through the physical medium of the building automation controller 110. The data link layer 116 is a higher-level layer than the physical layer 118 and controls data communication on the communication network 104 and the building network 108. The data link layer 116 may include a state machine that manages the transitions of the building automation controller 110 from one state to another. The network layer 114 is a higher-level layer than the data link layer 116 and the physical layer 118 and manages the physical paths of data within networks 104 and 108. The application layer 112 is a higher-level layer than the network layer, data link layer, and physical layers 114-118 and allows application users to access and control network services.
[0019] As described above, the building automation controller 110 can include a state machine (e.g., a component / application), which is executed by a processor by accessing firmware / software executable instructions from memory elements. This state machine facilitates message communication between communication / building networks 104, 108 and field devices 106, such as HVAC, lighting, and shading devices (actuators, sensors) connected to ports of the building automation controller 110 (or via a link bus). Examples of messages communicated between the management workstation 102 and the building automation controller 110 include, but are not limited to, value change (COV) notifications, alarm notifications, read / write services, and acknowledged private services.
[0020] See Figure 2 The illustration shows a system component 200 of a building automation controller 110 in an example embodiment. System component 200 includes one or more communication lines 202 for directly or indirectly interconnecting other system components. Other system components include one or more communication components 204, one or more processors 206, and one or more memory components 208. The communication component 204 communicates with other entities via wired or wireless networks. The communication component 204 communicates (i.e., receives and / or transmits) associated data with one or more devices of system 100 and their associated devices. The communication component 204 may utilize wired or wireless technologies for communication.
[0021] The processor or processors 206 are capable of sending data to other components of system component 200 and processing commands received from said other components, such as information from communication component 204 or memory component 208. Each application includes executable code to provide specific functionality to the processor 206 and / or the remaining components of controller 110. Examples of applications that can be executed by processor 206 include, but are not limited to, application module 210 and network driver module 212 (“Network Driver”). Application module 210 is capable of providing one or more data requests to a queue of building automation controller 110. Network driver module 212 is capable of retrieving messages from said queue in response to receiving a network token from a master-slave token protocol network. Network driver module 212 is also capable of determining that the field device sending DER message 106 is not communicating and, in response, sending an error PDU message to application module 210.
[0022] The data stored in memory element 208 is information that modules of processor 206 may reference and / or manipulate to perform functions of controller 110. Examples of data associated with controller 110 and stored by memory element 208 may include, but are not limited to, firmware instructions 214 and state machine data 216. Firmware instructions 214 provide data to processor 206 to perform general and specific operations of building automation controller 110. As described above, a portion of firmware instructions 214 includes a network stack, which may include one or more layers, such as application layer 112, network layer 114, data link layer 116, and physical layer 118. State machine data 216 provides information to processor 206 to execute a state machine that transitions building automation controller 110 from one state to another. It should be understood that, for some implementations, state machine data 216 may be included in firmware instructions 214.
[0023] System component 200 may include an input / output component 218 that manages one or more input components and / or output components. The input / output component 218 of system component 200 includes a wired or wireless connection 220, such as a port, for communicating with field devices 106 on the building network 108. The input / output component 218 of system component 200 may also include one or more visual, audio, mechanical, or other components that receive and / or provide information to the user / operator of controller 110.
[0024] It should be understood that Figure 2 Provided for illustrative purposes only to show an example implementation of the building automation controller 110, and not intended as a complete illustration of the various components that the device may utilize. The building automation controller 110 can include... Figure 2 Various other components, not shown, may include combinations of two or more components, or divide a particular component into two or more separate components, and are still within the scope of this invention. Furthermore, components 200 may be directly or indirectly coupled to each other to perform operations of the building automation controller 110. For example, processor 206 may be directly or indirectly coupled to input / output component 218.
[0025] Referring to Figure 3, a timing diagram is shown illustrating operation 300 of a state machine operable to employ the techniques described herein in an example embodiment. The state machine is located at least partially at the data link layer 116 of the network driver module 212. In some embodiments, operation 300 is adapted to the building automation controller 1110 so that erroneous PDUs can be correctly intercepted and processed by the data link layer 116 and / or the network driver module 212. Transmitting erroneous PDUs to other devices (e.g., conventional devices that cannot recognize such emulated messages) may produce unintended consequences. In other embodiments, if the network is a set of devices 106 that correctly understand erroneous PDUs, operation 300 can be adapted to all devices in the building network 108.
[0026] The firmware 214 of the building automation controller 110 may include an application 302 (e.g., a BBS application), a drive queue 304 (e.g., an MSTP drive queue), a network driver 306 (e.g., an MSTP driver), a transceiver 308 (e.g., a UART), and one or more other devices 310 (e.g., field devices). The operation 300 of the state machine can be executed by the application 302 (module 210) and the network driver 306 (module 212) with the support of one or more other components.
[0027] In Figure 3, the first request 314 is a successful sequence of communication with the "other device". In the second request 328, the device fails (i.e., malfunctions) and is not communicating. After a threshold time period following the transmission of the DER message, the state machine (i.e., network driver 306) returns an error message to application 302 indicating that no response has been received. In the third request (340) and the fourth request (348), network driver 306 learns from the second request 328 that the target field device 310 is not communicating, and therefore subsequent data requests in the queue are discarded.
[0028] Figure 3 illustrates several aspects 300 of a method for optimizing building network performance based on device failure. Application 302 is a high-level application that provides (312) one or more data requests to queue 304 of building automation controller 110. Examples of data requests include, but are not limited to, analog input current values, analog input states, analog input priority arrays, and analog input abandon default values. After enqueuing (312) one or more data requests, network driver 306 is able to receive a network token from building network 108 (e.g., a master-slave token protocol network) and, in response to receiving the network token, retrieve (318) messages in the queue. Building automation controller 110, in response to identifying the data request through the high-level application of the building automation controller, transmits (320) a Data Expectation to Reply (DER) message to field device 310. In this context, identifying the data request includes retrieving or receiving data requests from application 302 and / or network driver 304.
[0029] The first request 314 indicates normal operation, in which network driver 306 determines that the DER message sent by field device 310 is communicative and therefore there is no error. Network driver 306 determines that field device 310 is communicative because it has received a response from the field device. In some implementations, network driver 306 can receive (322) a response to the DER message from field device 310. In some implementations, network driver 306 can receive (324) a delayed response message from the field device. In response to receiving (322, 324) the response, network driver 306 transmits (326), i.e., sends a response with no error message, to higher application 302. The response with no error message indicates to application 302 that the requested data has been received and that the data can be provided to the application as appropriate.
[0030] The second request 328 indicates an erroneous operation, in which network driver 306 determines that the field device 310 to which the DER message was sent is not communicating, and therefore an error exists. Network driver 306 is able to receive (330) a network token and, in response to receiving the network token, retrieve (332) a message from the queue. Building automation controller 110 transmits (324) a DER message to field device 310 in response to recognizing a request for data. After transmitting (320) the DER message to field device 310, network driver 306 determines (336) that the field device to which the DER message was sent is not communicating. In some implementations, network driver 306 can determine (336) that the field device is not communicating based on a timeout response recognized at the network driver (e.g., generated or received) when the lack of a response to the DER message reaches a threshold time period.
[0031] In response to determining (336) that the field device is not communicating, network driver 306 sends (338), i.e., sends a reply error message, i.e., an error PDU message, to higher application 302. The error PDU message indicates an error state caused by a non-responsive protocol data unit of BACnet. In contrast to conventional systems, network driver 306 forges and sends back an "error" indicating a communication timeout to application 302, which indicates that the target field device is not communicating. At this time, application 302 can continue to perform other operations without waiting for a further reply. Network drivers 212 and 306 run at the data link layer 116 of the BACnet stack of building automation controller 110, while higher applications 210 and 302 run at the application layer 112 of the BACnet stack, which is higher than the data link layer 116. Applications 210 and 302 execute the functions of building automation controller 110 without further delay in response to receiving the (338) error PDU message from network drivers 212 and 306. One advantage is that advanced applications receive immediate feedback if any communication is lost on the building network.
[0032] The third and fourth requests 328 and 340 represent aspects of operation 300 after network driver 306 determines that the field device 310 to which the DER message was sent is not communicative. Network driver 306 is able to receive (342, 350) a network token and, in response to receiving the network token, retrieve (344, 352) the next message from the queue. Since network driver 306 knows from the second request 328 that the target field device 310 is not communicative, network driver 306 does not send any type of DER message to the field device. Instead, network driver 306 discards subsequent data requests in the queue and, in response to identifying (344, 352) the next message in the queue, sends (346, 354) another error PDU message to higher-level application 302.
[0033] Referring to Figure 4, a timing diagram is shown illustrating other operations 400 of the state machine in the example implementation, which can employ the techniques described herein. Operation 400 of Figure 4 is similar to operation 300 of Figure 3, but operation 400 of Figure 4 allows for retries using simulated faulty PDUs to minimize false failures in poorly performing networks. Specifically, advanced application 302 may retransmit a previously transmitted data request to drive queue 304 or network driver 306 in response to receiving a (402) faulty PDU message. In some implementations, advanced application 302 may retransmit (404, 406) a previously transmitted data request to drive queue 304 or network driver 306 for subsequent requests following the receipt of the faulty PDU message.
[0034] Additionally, as used herein, a processor corresponds to any electronic device configured to process data via hardware circuitry, software, and / or firmware. For example, the processor described herein can correspond to one or more (or combinations thereof) of a microprocessor, CPU, or any other integrated circuit (IC) or other type of circuitry in a data processing system capable of processing data. It should be understood that a processor described or declared as configured to perform a particular said / stated process or function can: correspond to a CPU that executes computer / processor-executable instructions stored in memory in software and / or firmware to perform such said / stated process or function; and / or can correspond to an IC hardwired to have processing circuitry (e.g., an FPGA or ASIC IC) to perform such said / stated process or function.
[0035] It should also be understood that a processor described or declared as configured to perform a particular said / declared process or function may correspond to a combination of a processor and software / firmware instructions loaded / installed in the memory (volatile and / or non-volatile) that are currently being executed and / or available for execution by the processor to cause the processor to perform the said / declared process or function. Therefore, even if the processor is powered off or is executing other software / firmware, it can correspond to the said / declared processor configured to perform the specific processes and functions described / declared herein, provided that the software / firmware instructions are installed in a storage device (e.g., non-volatile memory) operatively connected to the processor in a manner set to be executed by the processor (when started by a user, hardware, and / or other software).
[0036] Furthermore, the phrase "at least one" preceding an element (e.g., a processor) configured to perform more than one function / process can correspond to one or more elements (e.g., processors) that each perform such functions / processes, and can also correspond to two or more elements (e.g., processors) that each perform different functions / processes of the one or more different functions / processes.
[0037] It should be noted that although this disclosure is described in the context of a fully functional system and / or a series of actions, those skilled in the art will understand that at least a portion of the mechanisms of this disclosure and / or the actions described herein can be distributed in any of the various forms of computer / processor-executable instructions (e.g., the software and / or firmware instructions) contained in a non-transient machine-usable, computer-usable, or computer-readable medium, and this disclosure applies equally regardless of the specific type of instruction or data-bearing medium or storage medium actually used to implement the distribution. Examples of non-transient machine-usable / readable or computer-usable / readable media include ROM, EPROM, magnetic tape, hard disk drive, SSD, flash memory, CD, DVD, and Blu-ray disc. Computer / processor-executable instructions can include routines, subroutines, programs, applications, modules, libraries, and / or the like. Furthermore, it should be understood that computer / processor-executable instructions may correspond to and / or be generated from source code, bytecode, runtime code, machine code, assembly language, Java, JavaScript, Python, C, C#, C++, or any other form of code that can be programmed / configured to cause at least one processor to perform the actions and features described herein. Furthermore, the results of the stated / declared process or function may be stored in a computer-readable medium, displayed on a display device and / or the like.
[0038] Figure 5 A block diagram of a data processing system 500 (e.g., management workstation 102, controllers, and / or other devices) is shown, wherein one implementation is possible for some types of devices described herein and / or other systems operably configured to perform the functions and processes described herein using computer / processor-executable instructions, circuitry, or other means. The illustrated data processing system includes at least one processor 502 (e.g., CPU) capable of being connected to one or more bridges / controllers / buses 504 (e.g., northbridge, southbridge). For example, one of the buses 504 may include one or more I / O buses, such as a PCI Express bus. In the depicted example, main memory 506 (RAM) and a graphics controller 508 may also be connected to the various buses. The graphics controller 508 may be connected to one or more display devices 510 (e.g., LCD or AMOLED displays, monitors, VR headsets, and / or projectors). It should also be noted that the processor 502 may include CPU cache memory. Furthermore, in some implementations, one or more controllers (e.g., graphics controller, southbridge) may be integrated with the CPU (on the same chip or die). Examples of CPU architectures include IA-32, x86-64, and ARM processor architectures.
[0039] Other peripheral devices connected to one or more buses may include a communication controller 512 (Ethernet controller, Wi-Fi controller, cellular controller) for connecting to a local area network (LAN), wide area network (WAN), cellular network and / or other wired or wireless network 514 or communication devices.
[0040] Further components connected to various buses may include one or more I / O controllers 516, such as USB controllers, Bluetooth controllers, and / or dedicated audio controllers (connected to speakers and / or microphones). It should also be understood that various peripheral devices may be connected to the I / O controller (via various ports and connections), including input devices 518 (e.g., keyboards, mice, pointers, touchscreens, touchpads, drawing tablets, trackballs, buttons, keypads, game controllers, gamepads, cameras, microphones, scanners, motion sensing devices that capture motion gestures), output devices 520 (e.g., printers, speakers), or any other type of device capable of providing input to or receiving output from the data processing system.
[0041] Additionally, it should be understood that many devices, referred to as input devices or output devices, are capable of both providing input and receiving output in communication with the data processing system. For example, processor 502 can be integrated into a housing (such as a tablet computer) that includes a touchscreen that functions as both an input device and a display device. Furthermore, it should be understood that some input devices (such as laptop computers) can include multiple different types of input devices (e.g., touchscreens, touchpads, and keyboards). Additionally, it should be understood that other peripheral hardware 522 connected to I / O controller 516 can include any type of device, machine, or component configured to communicate with the data processing system.
[0042] Additional components connected to various buses can include one or more storage controllers 524 (e.g., SATA). The storage controller can connect to storage devices 526, such as one or more storage drives and / or any associated removable media, which can be any suitable non-transitory machine-usable or machine-readable storage medium. Examples include non-volatile devices, volatile devices, read-only devices, writable devices, ROM, EPROM, magnetic tape storage, hard disk drives, solid-state drives (SSDs), flash memory, optical disc drives (CD, DVD, Blu-ray), and other known optical, electrical, or magnetic storage devices and / or computer media. Additionally, in some examples, storage devices (such as SSDs) can be directly connected to I / O buses 504, such as the PCI Express bus.
[0043] The data processing system according to embodiments of this disclosure can include an operating system 528, software / firmware 530, and a data repository 532 (which may be stored on storage device 526 and / or memory 506). Such an operating system may employ a command-line interface (CLI) shell and / or a graphical user interface (GUI) shell. The GUI shell allows multiple display windows to be presented simultaneously in the graphical user interface, each providing an interface to different applications or different instances of the same application. A cursor or pointer in the graphical user interface can be manipulated by a user using a pointing device such as a mouse or touchscreen. The cursor / pointer position can be changed and / or events (such as clicking a mouse button or touching a touchscreen) can be generated to initiate a desired response. Examples of operating systems that can be used in the data processing system include Microsoft Windows, Linux, UNIX, iOS, and Android operating systems. Additionally, examples of data repositories include data files, data tables, relational databases (e.g., Oracle, Microsoft SQL Server), database servers, or any other structure and / or device capable of storing data that can be retrieved by a processor.
[0044] The communication controller 512 can be connected to a network 514 (which may or may not be part of the data processing system 500), which can be any local, wide area, remote, private, and / or public data processing system network or combination of networks known to those skilled in the art, including the Internet. The data processing system 500 can communicate via the network 514 with one or more other data processing systems, such as server 534 (which may, in combination, correspond to a larger data processing system). For example, the larger data processing system can correspond to multiple smaller data processing systems implemented as part of a distributed system, wherein processors associated with several smaller data processing systems can communicate via one or more network connections and can collectively perform tasks described as being performed by a single larger data processing system. Therefore, it should be understood that, when referring to a data processing system, such a system can be implemented across several data processing systems organized in a distributed system that communicates with each other via a network.
[0045] It should also be understood that the term "controller" means any device, system, or part thereof that controls at least one operation, whether such device is implemented in hardware, firmware, software, or any combination thereof. It should be noted that the functionality associated with any particular controller can be centralized or distributed, whether local or remote. The described processor and memory can be included in the controller. Furthermore, the controller can correspond to the aforementioned data processing system or any other hardware circuit capable of controlling at least one operation.
[0046] Additionally, it should be understood that the data processing system can include virtual machine architectures or virtual machines in a cloud environment. For example, processor 502 and associated components can correspond to a combination of one or more virtual machine processors operating in one or more physical processors of a physical data processing system. Examples of virtual machine architectures include VMware ESCi, Microsoft Hyper-V, Xen, and KVM.
[0047] Those skilled in the art will understand that the hardware depicted for a data processing system can vary for a particular implementation. For example, the data processing system 500 in this example may correspond to a controller, computer, workstation, server, PC, laptop computer, tablet computer, mobile phone, and / or any other type of device / system capable of processing data and performing the functions and features described herein that are associated with the operation of the data processing system, computer, processor, software components, and / or controller discussed herein. The examples depicted are provided for illustrative purposes only and are not intended to imply any architectural limitations with respect to this disclosure.
[0048] Those skilled in the art will recognize that, for simplicity and clarity, this document does not depict or describe the complete structure and operation of all data processing systems suitable for use with this disclosure. Rather, only the parts of a data processing system that are specific to this disclosure or necessary for understanding this disclosure are depicted and described. The remaining construction and operation of the data processing system 500 may conform to any of the various current implementations and practices known in the art.
[0049] This application is incorporated in its entirety by reference of U.S. Patent No. 10,348,617 B2, entitled "System and Method for Stabilizing a BACnet MSTP Network when Failures Occur," inventors William Choi and Timothy Stevens, and was granted on July 9, 2019.
[0050] As used herein, the terms “component” and “system” are intended to encompass hardware, software, or a combination of hardware and software. Thus, for example, a system or component can be a process, a process executing on a processor, or a processor itself. Furthermore, a component or system can reside on a single device or be distributed across several devices.
[0051] Furthermore, it should be understood that, unless explicitly limited in some examples, the words or phrases used herein should be interpreted broadly. For example, the terms “include” and “comprise” and their derivatives mean including, but not limited to. The singular forms of “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. Additionally, the term “and / or” as used herein refers to and covers any and all possible combinations of one or more associated listed items. The term “or” is inclusive, meaning and / or, unless the context clearly indicates otherwise. The phrases “associated with” and “associated therewith” and their derivatives may mean including, being included, interconnected, containing, being contained within, connected to or linked to, coupled to or coupled to, able to communicate with, collaborate, intertwine, be parallel, be adjacent, be bound to or tied to, have, have the properties of, etc.
[0052] Furthermore, although the terms “first,” “second,” “third,” etc., may be used herein to refer to various elements, information, functions, or actions, these elements, information, functions, or actions should not be limited by these terms. Rather, these numerical adjectives are used to distinguish different elements, information, functions, or actions from one another. For example, a first element, information, function, or action may be referred to as a second element, information, function, or action, and similarly, a second element, information, function, or action may be referred to as a first element, information, function, or action, without departing from the scope of this disclosure.
[0053] Additionally, the term "proximity" can mean: an element is relatively close to but does not touch another element; or an element touches another part, unless the context clearly indicates otherwise. Furthermore, the phrase "based on" is intended to mean "at least partially based on," unless otherwise clearly stated.
[0054] Although exemplary embodiments of this disclosure have been described in detail, those skilled in the art will understand that various changes, substitutions, modifications and improvements may be made to the disclosure herein without departing from the spirit and scope of the broadest form of this disclosure.
[0055] No description in this application should be construed as implying that any particular element, step, action, or function is a necessary element to be included within the scope of the claims: the scope of protection of the patent subject matter is defined only by the granted claims. Furthermore, unless the precise phrase “means for” is followed by a participle, these claims are not intended to invoke a means-plus-function claim construction.
Claims
1. A method for optimizing building network performance based on equipment failure, comprising: In response to recognizing a data request from an advanced application of the building automation controller, the building automation controller sends a Data Expectation Response (DER) message to the field device; The network driver of the building automation controller determines that the field device receiving the DER message is not communicating. In response to determining that the field device is not communicating, an error PDU message is transmitted from the network driver of the building automation controller to the advanced application of the building automation controller.
2. The method according to claim 1, wherein, The error PDU message indicates an error state caused by a non-responding protocol data unit of BACnet.
3. The method according to claim 1, wherein, The network driver runs at the data link layer of the BACnet protocol stack of the building automation controller, and the advanced application runs at the application layer of the BACnet protocol stack, which is at a higher level than the data link layer.
4. The method according to claim 1, wherein, Determining that the field device is not communicating includes determining that the field device is not communicating based on a timeout response identified at the network driver due to the failure to respond to the DER message within a threshold time period.
5. The method of claim 1, further comprising, in response to receiving a reply to the DER message from the field device or receiving a reply delay message from the field device at least once, transmitting a reply non-error message from the network driver to the advanced application.
6. The method according to claim 1, wherein, In response to the error PDU message received by the advanced application from the network driver, the functions of the building automation controller are executed without further delay.
7. The method according to claim 1, further comprising: The advanced application provides one or more requests for data to the queue of the building automation controller; as well as In response to receiving a network token from the master-slave token protocol network, the network driver retrieves a message from the queue.
8. A system for optimizing building network performance based on equipment failure, comprising: A building automation controller, including advanced applications and network drivers, sends a Data Expectation Response (DER) message to field devices in response to recognizing a data request from the advanced applications. The network driver of the building automation controller determines that the field device receiving the DER message is not communicating, and in response to determining that the field device is not communicating, transmits an error PDU message to the advanced application of the building automation controller.
9. The system according to claim 8, wherein, The error PDU message indicates an error state caused by a non-responding protocol data unit of BACnet.
10. The system according to claim 8, wherein, The network driver runs at the data link layer of the BACnet protocol stack of the building automation controller, and the advanced application runs at the application layer of the BACnet protocol stack, which is at a higher level than the data link layer.
11. The system according to claim 8, wherein, The network driver determines that the field device is not communicating based on a timeout response identified at the network driver because it did not respond to the DER message within a threshold time period.
12. The system according to claim 8, wherein, In response to receiving a reply to the DER message from the field device or a reply delay message from the field device, the network driver sends a reply non-error message to the advanced application.
13. The system according to claim 8, wherein, The building automation controller, in response to the advanced application receiving the error PDU message from the network driver, executes the function without further delay.
14. The system according to claim 8, wherein, The advanced application provides one or more requests for data to the queue of the building automation controller; and The network driver retrieves a message from the queue in response to receiving a network token from the master-slave token protocol network.
15. A non-transitory computer-readable medium comprising executable instructions that, when executed, cause at least one processor of a building automation controller to optimize building network performance based on device failures, by: In response to the recognition of a data request from an advanced application of the building automation controller, a Data Expectation Response (DER) message is sent to the field device; The network driver determines that the field device receiving the DER message is not communicating; as well as In response to determining that the field device is not communicating, an error PDU message is transmitted from the network driver to the advanced application.
Citation Information
Patent Citations
System and method for stabilizing a BACnet MSTP network when failures occur
US10348617B2
