Building automation system with edge device self-monitoring and repair

Abstract

The invention provides an edge controller for building equipment, and the edge controller comprises a circuit system. The circuitry is programmed to provide a data bus located locally to the edge controller, a plurality of containerized applications executing on the edge controller by exchanging data with the data bus; and a controller health application executing on the edge controller and monitoring health of the plurality of containerized applications via the data bus.

Description

[0001] Cross-reference to related applications

[0002] This application claims priority and benefit to U.S. nonprovisional application No. 18 / 821,946, filed August 30, 2024, and U.S. provisional patent application No. 63 / 686,553, filed August 23, 2024, both of which are incorporated herein by reference in their entirety. Background Technology

[0003] This disclosure generally relates to building equipment and building automation systems. Conventional building automation systems involve complex architectures that may require manual configuration by field technicians of numerous devices, monitoring and field controllers, internal servers, external servers, and other infrastructure to establish and maintain the system. Such architectures may be suitable for large facilities but are structurally very different from building automation systems designed for smaller entities, leading to additional complexity (e.g., driven by a greater number of different tools and platforms) and preventing or complicating comparisons between facilities of different types and sizes. Furthermore, each of these building devices may have limited functionality or perform limited types of logic, and the different devices, including different equipment, sensors, data sources, etc. (within a given building), often use different protocols and data formats, which creates barriers to integration and reduces interoperability between building devices. This disclosure aims to address these and other challenges. Summary of the Invention

[0004] One specific embodiment of this disclosure is an edge controller for building equipment. The edge controller includes a circuitry programmed to provide a data bus located locally on the edge controller, multiple containerized applications executing on the edge controller by exchanging data with the data bus, and a controller health application executing on the edge controller and monitoring the health of the multiple containerized applications via the data bus.

[0005] In some embodiments, the controller health application is configured to provide health monitoring via data records using at least a subset of data exchanged between multiple containerized applications and a data bus. The controller health application may be configured to execute a self-healing routine for the edge controller in response to detecting a problem in at least a first application among the multiple containerized applications. The self-healing routine may include using at least one artificial intelligence model to identify a solution to the problem and automatically implementing that solution at the edge controller.

[0006] In some embodiments, the controller health application is configured to record additional data streaming on a data bus in response to detecting a problem in at least one of a plurality of containerized applications. The controller health application may be configured to record additional data by saving the additional data to a local data store of the edge controller. In some embodiments, the circuitry includes a port coupled to the data bus to receive measurements from a sensor and to provide an output to the sensor, wherein the device health application is configured to provide the output to the sensor in response to detecting a problem, the output causing the sensor to stream additional data to the data bus.

[0007] In some embodiments, the circuitry is also programmed to provide a network connection to a remote server. The device health application can be configured to generate a packet containing additional data and provide the packet to the remote server via the network connection.

[0008] In some embodiments, the controller health application is also configured to attempt to execute multiple solutions to multiple problems for multiple applications, record the execution results of the multiple solutions to multiple problems for multiple applications, and locally train a machine learning model of the controller health application on an edge device to determine future solutions based on the records.

[0009] In some embodiments, the controller health application is configured to check the connectivity of known endpoints, check network connectivity in response to a lack of connectivity of at least one of the endpoints, and, in response to a combination of network connectivity and a lack of connectivity of at least one of the endpoints, collect records from a subset of multiple containerized applications based on a subset of the endpoints, and take corrective actions based on the records.

[0010] In some embodiments, the controller health application is configured to monitor streaming data when the edge controller abandons transmitting at least some of the streaming data on the data bus out of the edge controller.

[0011] Another specific embodiment of this disclosure is a building management system. This building management system includes device units operable to heat, cool, or ventilate building spaces; sensors configured to measure the condition of the building spaces; and an edge controller configured to receive measurements of the building space conditions from the sensors and control the device units. The edge controller is also programmed to provide a data bus locally on the edge controller and is configured to receive measurement results from the sensors and, by exchanging data with the data bus, enable control outputs to be provided to the device units and multiple containerized applications executing on the edge controller. At least one of the multiple containerized applications generates the control output based on the measurements; and a controller health application, executing on the edge controller and monitoring the health of the multiple containerized applications via the data bus.

[0012] In some embodiments, the edge controller is located at a building site close to the device units and sensors. In some embodiments, the controller health application is configured to provide health monitoring via data records using at least a subset of data exchanged between multiple containerized applications and a data bus, and to execute a self-healing routine of the edge controller in response to detecting a problem in at least a first application among the multiple containerized applications.

[0013] In some embodiments, the self-healing routine includes using at least one artificial intelligence model to identify a solution to the problem and automatically implementing that solution at the edge controller. In some embodiments, the controller health application is configured to check connectivity with one or more endpoints. In some embodiments, the controller health application is configured to record additional data streaming on a data bus in response to detecting a problem in at least one of a plurality of containerized applications. The controller health application may be configured to cause a sensor to provide additional data to the data bus in response to detecting a problem. The sensor may be a camera, and the additional data may be streaming video. Attached Figure Description

[0014] This disclosure will be more fully understood from the following detailed description, taken in conjunction with the accompanying drawings, wherein like reference numerals refer to like elements, in the drawings:

[0015] Figure 1 This is a first block diagram of a building automation system according to some embodiments.

[0016] Figure 2 This is a second block diagram of a building automation system according to some embodiments.

[0017] Figure 3 This is a block diagram of an edge circuit system and a cloud system for a building automation system according to some embodiments.

[0018] Figure 4 This is an exemplary illustration of a cloud manager interface for managing logic executed by an edge circuit system, according to some embodiments.

[0019] Figure 5 This is an exemplary illustration of an event viewer interface according to some embodiments, showing an event alert generated by an edge circuit system using logic managed by a cloud manager.

[0020] Figure 6 This is a first view in a distributor dashboard according to some embodiments.

[0021] Figure 7 This is a second view in the distributor dashboard according to some embodiments.

[0022] Figure 8 This is a block diagram of an automated system according to some embodiments.

[0023] Figure 9 This is a flowchart of a process for monitoring connectivity according to some embodiments.

[0024] Figure 10 This is a flowchart of a process for diagnosing and resolving connectivity problems, according to some embodiments.

[0025] Figure 11 This is a diagram of logic for monitoring connectivity according to some embodiments. Detailed Implementation

[0026] Referring generally to the accompanying drawings, advancements in building automation systems are illustrated according to various embodiments. For example, in some embodiments, the edge device is equipped with a controller health application that operates locally on the edge device and monitors the health of applications exchanging data with the common data bus via a common data bus. The controller health application can detect and diagnose problems with controller performance in real time, using data that may be unavailable through other methods such as remote fault diagnosis or customer service centers. The controller health application can, for example, automatically (e.g., using artificial intelligence) determine actions to be taken to resolve (e.g., self-heal) the detected controller operational problems and automatically perform such self-healing, thereby providing improved reliability to the edge device, reducing downtime, etc. The edge device can also be configured to store packages of recorded data associated with detected problems (e.g., recording triggered in response to problem detection), such as reinforcement learning for models used for problem detection and solutions and / or for presentation to external systems or use, such as summaries of data represented in the bundled records (e.g., generated by generative artificial intelligence).

[0027] In various embodiments, the additional advancements described herein leverage multi-domain expertise to embed intelligence and data at the edge, enabling faster deployment of building equipment and building automation systems via a plug-and-play architecture, seamless data sharing, and the optimization of multiple competing needs using organized data. They provide a scalable architecture capable of operating in buildings of varying sizes, from large / complex (e.g., hospitals, headquarters) to light commercial (e.g., retail storefronts, small offices), offering a hybrid architecture with on-premises capabilities and cloud readiness, future-proofing through over-the-air updates, providing a high level of cybersecurity, and / or providing convenient access to advanced digital functions. The building automation systems described herein can be implemented in various embodiments and at various scales, including fixed-function controls, configurable controls, pre-configured functions, and / or programmable / fully customizable functions.

[0028] In some embodiments, this disclosure contemplates factory-shipped packaged control circuitry systems (i.e., as integrated packages, on a single pallet, within a shared enclosure, etc.) for building equipment units (e.g., roof units, coolers, etc.) where onboard / integrated circuitry systems provide a variety of advanced data ingestion, machine learning, expression-based pattern recognition, and / or other control and analytics capabilities, as detailed below. In some embodiments, this disclosure also contemplates retrofitting existing buildings or equipment by installing such circuitry systems into existing facilities. Such circuitry systems may also include embedded cloud bridging technologies and / or building twin technologies to enable seamless and direct interaction between hybrid digital capabilities and cloud services (including cloud-based digital twins, edge-based digital twins, or combinations thereof). This unification of such advanced capabilities at the edge can drive local improvements in the internal operation of building equipment units, plug-and-play high-level cloud analytics and control optimization, and automated data standardization and aggregation for visualization across facility, owner, customer, and equipment types.

[0029] These and other features and advantages are described in further detail below with reference to the accompanying drawings.

[0030] Now for reference Figure 1A building automation system 100 is illustrated according to some embodiments. The building automation system 100 is shown as including a cloud layer 102 and an inner layer 104, wherein the inner layer 104 includes device units 106 having an edge circuitry system 108 (e.g., an onboard circuitry system, a local circuitry system) that can communicate directly with the cloud layer 102, particularly with the cloud system 110 of the cloud layer 102 (e.g., solely via network communication infrastructure, an internet architecture, without intermediate supervisory or field controllers, etc.). The cloud layer 102 is also shown as including a cloud application 112 and a remote service 114, for example, either or both of which can be executed by or via the cloud system 110. A unified pane 116 is accessible via the cloud layer 102 and / or the inner layer 104 and provides visualization of the building automation system 100 and its associated data, and allows users to interact with it. The inner layer 104 is shown as including various data sources, such as security sensors 118, fire alarms 120, and temperature sensors 122.

[0031] Although Figure 1 Safety sensor 118, fire alarm 120, and temperature sensor 122 are shown. In various embodiments, the data source may include various sensors (safety sensors, cameras, door sensors, smoke detectors, fire sensors, indoor temperature sensors, pressure sensors, outdoor temperature sensors, humidity sensors, occupancy sensors, air quality sensors, flow meters, power meters, etc.), devices (e.g., roof units, coolers, air handling units, variable air volume boxes, etc.), or other devices or systems (e.g., building dispatch systems, thermostats, nurse call systems, etc.). The data source may include a local source located in the same facility as the roof unit, an internal source at or near the roof unit, a peer source communicating with the onboard circuitry in a peer-to-peer manner, and / or an external source communicating directly with the onboard circuitry or only via devices located in the same facility. The data source may provide (e.g., substantially continuously streaming, periodically transmitting, etc.) signals (data, information, etc.) to the edge circuitry system 108.

[0032] Device unit 106 and edge circuit system 108 may share housing 109, for example, wherein heating, ventilation, or cooling components of device unit 106 and edge circuit system 108 (e.g., compressor, evaporator, valve, actuator, fan, damper, cooling coil, heating coil, etc.) are coupled to and / or encapsulated within housing 109. In some embodiments, device unit 106 and edge circuit system 108 are packaged together in a factory or warehouse and shipped to the building site as an integrated package (e.g., coupled to a common pallet) for installation. Figure 1In this example, device unit 106 is a roof unit. In other embodiments, device unit 106 may be one or more of a variety of other types of building equipment (e.g., coolers, air handling units, variable air volume boxes, cooling towers, actuators, valves, air purifiers, water heaters, boilers, thermal energy storage devices, batteries, variable refrigerant flow outdoor units, variable refrigerant flow indoor units, lighting fixtures, controllable safety devices, controllable fire safety devices, etc.). Device unit 106 is operable to influence variable conditions of the building (e.g., temperature, humidity, airflow, air quality, pressure, brightness, lighting color temperature, etc.).

[0033] like Figure 1 As shown, device unit 106 and edge circuit system 108 include a bridging communication layer 124 that enables communication between inner layer 104 and cloud layer 102. Bridging communication layer 124 is configured to provide bridging between edge circuit system 108 and cloud system 110, such as as described in U.S. Provisional Patent Application No. 63 / 296,078, filed January 3, 2022, the entire disclosure of which is incorporated herein by reference. Edge circuit system 108 may store a portion of a digital twin of the facility served by device unit 106, such as a digital twin with event-rich and contextual information as described in U.S. Application No. 17 / 504,121, filed October 18, 2021, the entire disclosure of which is incorporated herein by reference. In some implementations, the bridging communication layer 124 may additionally or alternatively perform certain processing and / or storage, such as processing remote programming rules or artificial intelligence / machine learning routines and / or storing digital twins internally (such as at device unit 106).

[0034] Cloud 102 is shown as including cloud system 110 and associated cloud application 112 and remote service 114. Cloud application 112 may include fault prediction, detection, and diagnostic features that predict, detect, and / or diagnose faults in device unit 106, and in some embodiments, recommend maintenance or automatically induce changes in the control of device unit 106 to prevent or mitigate such faults. As another example, cloud application 112 may include an optimization application that performs optimizations configured to reduce utility costs, energy use, carbon emissions, or combinations thereof, such as complying with constraints to ensure occupant comfort, and provides control settings (e.g., zone temperature setpoints) to device unit 106 as outputs of such applications (e.g., as described in, for example, U.S. Patent Publication No. 2020 / 0041158, filed October 10, 2019, and / or U.S. Patent Application No. 17 / 668,791, filed February 10, 2022, the entire disclosure of which). The cloud application 112 is incorporated herein by reference. As another example, the cloud application 112 may include sustainability tools for managing pollution emissions (e.g., carbon emissions) and / or generating control settings for device unit 106 to achieve emission targets (e.g., net-zero energy consumption), such as those described in U.S. Provisional Patent Application No. 63 / 301,910, filed January 21, 2022, the entire disclosure of which is incorporated herein by reference. In some embodiments, the cloud application 112 may include tools for assessing and improving occupant, space / building, and / or environmental health, indoor air quality, and / or features related to infection risk, such as those described in U.S. Provisional Patent Application No. 63 / 230,608, filed August 6, 2021; U.S. Patent Application No. 17 / 459,963, filed August 27, 2021; and U.S. Provisional Patent Application No. 63 / 281,409, filed November 19, 2021, the entire disclosure of each of the foregoing applications is incorporated herein by reference. While these features are described as optional parts of cloud application 112, it should be understood that in various embodiments, aspects of the features may additionally or alternatively (e.g., in edge circuitry) The features are implemented as part of the inner layer 104 within system 108. For example, in some implementations, one or more of these or other features may be fully implemented within the edge circuit system 108, and in some implementations, a portion of the features may be implemented within the edge circuit system 108, while a portion may be implemented within the cloud application 112 (e.g., enabling the edge circuit system 108 and the cloud application 112 to work together to perform the features). For example, remote service 114 may enable expert access to data related to device unit 106 and expert intervention related to the operation of device unit 106.

[0035] In some implementations... Figure 1 The architecture shown can offer several advantages over more conventional multi-level building automation system (BAS) architectures. A multi-level BAS architecture can include, for example, edge devices such as rooftop units (RTUs), coolers, air handling units (AHUs), etc., and can further include multi-level controllers to interface with such units. For example, in this architecture, an edge device such as an RTU can interface with a field controller, which can be located close to the RTU or otherwise communicate directly with the RTU. The field controller can then interface with a supervisory controller, which can interact with local internal controls and / or the cloud or other off-site services.

[0036] In some embodiments of this disclosure, such as Figure 1 As shown, edge devices such as RTUs can interface directly with the cloud or other external systems / services via edge circuit system 108. Therefore, some embodiments of this disclosure provide a flattened architecture relative to a multi-tiered architecture and can, for example, eliminate the need for one or more intermediate controllers (e.g., field controllers, supervisory controllers, etc.). In some embodiments, some functionality of such devices can be implemented in edge circuit system 108, cloud application 112, or a mixture thereof.

[0037] This architecture can significantly reduce the time required to install a new building management system / building automation system (e.g., in some instances, reducing installation and configuration time from weeks to hours). The architecture supports over-the-air updates and remote serviceability via cloud layer 102. It can support high-level analytics that can be performed at cloud layer 102, internal layer 104 (e.g., at edge circuitry system 108), or a combination thereof. The architecture also enables faster and easier configuration of such analytics (e.g., in some cases, reducing the time to bring a specific analytics service online / activated, for example, from weeks to hours). The architecture can support automated configuration of various devices and services. In some implementations, the architecture can reduce or eliminate the need for multiple disjointed user interfaces, data models, and other tools, and instead allow for the application of a unified set of tools / models / interfaces across multiple devices / spaces / buildings / applications, etc.

[0038] It should be understood that, as utilized herein, the edge circuitry system does not require the described components / devices to be independent and distinct circuitry systems, such as circuitry systems independent of the circuitry systems of edge devices (such as roof units or coolers). Rather, in various embodiments, the edge circuitry system or other circuitry system described herein may be implemented as independent hardware and / or software, integrated with or part of existing hardware / software of existing devices (such as edge devices (e.g., roof units / coolers) or other internal computing devices (such as servers or controllers) or combinations thereof). In some embodiments, the edge circuitry system or other circuitry system described herein may be implemented as instructions stored on one or more computer-readable storage media (such as storage media of existing devices or independent storage media), which may be executed by one or more processors (e.g., processors of existing devices or other processors) to perform the functions described herein. In some embodiments, instructions may be added to one or more internal devices, such as by providing some or all of the instructions to the device during manufacturing or after installation / during operation via on-site or remote programming of the device.

[0039] Now for reference Figure 2 According to some embodiments, an enterprise system 200 is shown. The enterprise system 200 can be characterized as... Figure 1 The building automation system 100 is an extension for multiple facilities. Advantageously, the enterprise system 200 uses the same architecture as the building automation system 100, which is independent of the number of different facilities included in the enterprise system 200, the number of different equipment units included, and the size of one or more facilities. Therefore, the architecture and other features disclosed herein can be used across buildings, campuses, and enterprises of different sizes and complexities (including internal differences in size and complexity) without requiring architectural changes. In the example shown, the enterprise system 200 includes instances of cloud layer 102 and inner layer 104 at multiple buildings (shown as three retail branches, each with inner layer 104a, inner layer 104b, and inner layer 104c). The enterprise system 200 also includes instances of inner layers for different types of buildings, shown as an edge layer 202 for a headquarters building.

[0040] exist Figure 2In the example, cloud layer 102 includes cloud system 110, cloud application 112, and remote service 114, which are accessed by users via unified pane 116. Cloud layer 102 is also shown as including digital twin 204 and third-party cloud 206. Digital twin 204 can be a digital twin as described in U.S. Application No. 17 / 504,121, filed October 18, 2021, the entire disclosure of which is incorporated herein by reference. In various embodiments, third-party cloud 206 can be any cloud system, resource, service, etc., that provides data useful to cloud application 112, remote service 114, or digital twin 204 and / or uses the output of cloud application 112, remote service 114, digital twin 204, inner layers 104a-104c, or edge layer 202 to provide various functionalities.

[0041] The edge layer 202 of the headquarters building is shown as including equipment unit 208, which can be used with, for example... Figure 1 The device unit 106 of the inner layer 104 shown (and as in various examples) Figure 2 Different device types are present in the inner layers 104a to 104c. In various embodiments, the edge layer 202 may include multiple device units 208. For example, the device unit 106 for a retail branch may be a roof unit, while the headquarters building may have other plant equipment as one or more device units 208 (e.g., one or more coolers, one or more boilers, etc.), or may have a more complex / larger roof unit or a group of multiple roof units. The edge layer 202 also includes an edge circuit system 210 that is coupled to, encapsulated in, packaged in, distributed in, integrated with, etc., the device units 208. The edge circuit system 210 advantageously has a connection with... Figure 1 The edge circuit system 108 has the same or similar design, for example, with adjustments for use with the device type of device unit 208. Various data sources can be connected to this edge circuit system, as referenced above. Figure 1 ,in Figure 2 A complex system 212 (such as an internal system performance system, etc. (e.g., hosted on an internal server)) may be included and communicate directly with the edge circuit system 210 (e.g., without prior routing through the cloud system 110) and / or the cloud system 110. In some implementations, such a complex system 212 may be integrated as part of the edge circuit system 210.

[0042] Figure 2The scalability of the architecture of this disclosure, according to some embodiments, across different facilities, campuses, enterprises, real estate portfolios, equipment distribution networks, service areas, etc., is demonstrated. Although retail branches and headquarters are shown in the examples illustrated, various other combinations of different types of facilities are possible (e.g., residential, classroom, athletic, and laboratory facilities on university campuses; hospital, clinic, and pharmacy facilities on healthcare groups; storefronts, factories, and warehouses on consumer goods companies; hotels and corporate offices on hotel groups; stadiums and corporate offices on ownership groups; airport terminals and other airport operating facilities and / or office space; etc.). The architecture can implement services suitable for such facilities (e.g., using 3D building models of the relevant buildings) without modification. Figures 1 to 2 The diagram shows the underlying architecture of a building automation system.

[0043] Now for reference Figure 3 According to some embodiments, a detailed view of the interoperability between cloud layer 102 and edge circuit system 108 is shown. Edge circuit system 108 is shown as including a data ingestion layer 300, an analytics layer 302, and a data publishing layer 304. Cloud layer 102 is shown as including an analytics management section 306 and a cloud processing section 308. Analytics management section 306 interoperates with analytics layer 302 of edge circuit system 108, while cloud processing section 308 interoperates with data publishing layer 304.

[0044] Data ingestion layer 300 is configured to ingest data received from multiple sources in various data formats and using various data protocols, convert the data into a common data format, and provide the data in the common data format to the common data bus 310 of analysis layer 302. In some embodiments, data ingestion layer 300 and its elements may be implemented using features for ingesting and processing streaming data and / or datasets, as described in U.S. Patent No. 10,007,513, filed August 29, 2016; U.S. Patent No. 11,048,498, filed August 13, 2019; U.S. Patent No. 10,572,230, filed March 23, 2017; and / or U.S. Patent No. 10,564,941, filed March 23, 2017, the disclosures of which are incorporated herein by reference in their entirety. The common data format may be, for example, Brick format, or any other type of common data model. The data ingestion layer may apply tags to the data, such as tags indicating the type of entity, relationships between entities, such as location, event, asset, and place tags. The data ingestion layer 300 can also provide various preprocessing steps, including normalizing, aligning (e.g., arranging data from multiple sources into discrete values ​​at common frequency / time step intervals), filtering, cleaning, etc., of the data received at the data ingestion layer 300 before providing such data to the data bus 310.

[0045] like Figure 3 As shown, the data ingestion layer 300 includes multiple inputs 307 (ports, pins, wireless receivers, etc.) that receive signals (data, etc.) from a source 312 and provide such signals to MQTT agent 314, OPCUA agent 316, Modbus agent 318, DDS agent 320, and BACnet agent 322. MQTT agent 314 is configured to convert data from the MQTT protocol into a common data format used by the data bus 310 (e.g., data from IoT sensors). OPCUA agent 316 is configured to convert data from the OPCUA protocol into a common data format. Modbus agent 318 is configured to convert data (e.g., from building sensors) from the Modbus protocol into a common data format. DDS agent 320 is configured to convert data from the DDS protocol into a common data format. BACnet agent 322 is configured to convert data (e.g., internal data of building equipment, data from other building equipment) from the BACnet protocol into a common data format. Agents 314 to 322 may be selectively included or excluded based on the data protocol of the data source communicatively coupled to edge circuit system 108. This includes, in some examples, adding agents for a new protocol via over-the-air updates when a data source using a new protocol is connected. Agents 314 to 322 may transform data in real-time (e.g., in a substantially continuous stream), such that real-time data is provided to data bus 310. In alternative embodiments, such local data transformation avoids latency issues that could delay data processing, where such data transformation is performed at a remote server. While agents 314 to 322 may be implemented using software agents in some implementations, it should be understood that in other implementations, methods other than software agents may be used to implement the protocol mediation / conversion layer.

[0046] The analysis layer 302 is configured to execute one or more of a variety of logic types, including control logic (e.g., a PID feedback control loop), expression-based event processing and / or pattern recognition, and / or one or more machine learning or artificial intelligence algorithms / routines (e.g., machine learning algorithms specifically modified to have a smaller memory footprint, thus enabling edge execution). This logic is executed using data in a common data format from the data bus 310 and may include sending control signals to device units 106 (i.e., to electromechanical components that operate according to such control signals to influence the condition of the building) or transmitting results to the cloud layer 102 via the cloud connector 323 of the data publishing layer 304.

[0047] The analytics layer 302 is shown as including a data bus 310, an edge manager 324, a configurator 326, a metric 328, an analytics expression domain-specific language 330, an analytics engine 332, a software development kit 334, a product application 336, and other applications 338. The data bus 310, edge manager 324, configurator 326, metric 328, analytics expression domain-specific language 330, analytics engine 332, and software development kit 334 are shown exchanging information with the data bus 310, while in the illustrated demonstration, the other applications 338 and the product application 336 interoperate with the data bus 310 via the software development kit 334.

[0048] Edge Manager 324 interoperates with Cloud Manager 340 of the Analytics Management Section 306 of Cloud Layer 102. Cloud Manager 340 provides information and receives input from User Interface Console 342 (e.g., a browser-based interface hosted by Cloud Manager 340 and accessible from a personal computing device via the Internet). Cloud Manager 340 and User Interface Console 342 interact with Access Management System 344, which determines whether a user has permission to manage Edge Circuit System 108 (e.g., based on login credentials, etc.) and, in response to determining that the user has permission to manage Edge Circuit System 108, allows the user to access User Interface Console 342 and interact with Cloud Manager 340. An exemplary interface displayed by User Interface Console 342 and providing interaction with Cloud Manager 340 to manage analytics performed by Analytics Layer 302 is provided. Figure 4 The expression-based logic is shown and described below with reference to the expression. New or updated expression-based logic can be remotely transmitted to edge circuit system 108 to enable over-the-air updates of edge circuit system 108, and in some scenarios, to enable over-the-air updates of other similar edge circuit systems for similar edge devices in the network.

[0049] Cloud Manager 340 provides the ability to create and modify various logics executed by Analysis Layer 302. As an example, Cloud Manager 340 allows a user (via user interface console 342) to select or create expression-based logic for execution by Analysis Layer 302. For instance, Cloud Manager 340 can provide tools and methods for real-time dataflow programming languages ​​as described in U.S. Patent No. 10,977,0101, filed April 21, 2020, and / or U.S. Patent No. 10,127,022, filed March 23, 2017, the entire disclosure of which is incorporated herein by reference. Expression-based logic enables complex event processing that can perform real-time analysis of different data streams (e.g., collected on data bus 310), perform complex pattern recognition on high-frequency and asynchronous stream data, detect events in real time (enabling immediate responses such as closed-loop control actions), and handle machine learning preprocessing and post-processing. For example, expression-based logic can be selected or customized via cloud manager 340 to define fault diagnosis rules based on trends in data on data bus 310 (e.g., comparing the rates of change of different variables from different data sources). Such expression-based logic can be stored at analysis expression DSL 330 and executed by analysis engine 332 of analysis layer 302 of edge circuit system 108.

[0050] As another example, cloud manager 340 is configured to train a neural network (or other machine learning or artificial intelligence model) on historical data of configuration, events, performance, etc., of device unit 106 and / or other device units (e.g., similar device units serving a similar building). Cloud manager 340 may provide the trained neural network to edge manager 324. In some embodiments, cloud manager 340 modifies the trained model in a manner that reduces the memory and computing resources required to run the algorithm using the model and provides the modified model to edge circuit system 108. The model may be edge-transformed (“edge-ized”), as described in U.S. Patent Publication No. 2020 / 0327371, filed April 9, 2019, the entire disclosure of which is incorporated herein by reference. The modified (edge-transformed, edge-ized, etc.) model may be used by edge circuit system 108 to use a continuous data stream as input from data bus 310 and to produce inferences (predictions, diagnostics, control outputs) without communicating with cloud layer 102. For example, cloud manager 340 can periodically update the edge-transformed model in a closed-loop manner by interoperating with edge manager 324. The edge-transformed model can be stored on edge circuit system 108 by edge manager 324 and used in one or more machine learning algorithms, such as by analysis engine 332 of analysis layer 302. In some embodiments, the edge-transformed model is provided on data bus 310 so that it can be used by application 338 and product application 336 via SDK 334.

[0051] For example, the cloud manager 340 and the user interface console 342 can also enable various other automations or user-selected adjustments to the settings and control logic. For example, the user can select the temperature setpoint, the desired temperature range, preferences for comfort versus cost or energy or carbon savings that can be used by various control logics (e.g., PID feedback controllers, extreme value seekers, etc.), and analysis or model-based processes performed by the edge circuit system 108 (e.g., model predictive control, predictive maintenance, etc.).

[0052] The configurator 326 of the analysis layer 302 is configured to automatically determine the configuration for the edge circuit system 108 and device unit 106. This configuration may include multiple parameters that tune the edge circuit system 108 and device unit 106 to or toward ideal performance. In some embodiments, the configurator 326 uses expression-based event processing logic to estimate data from the data bus 310 and uses the results of such expression-based event processing logic to determine the configuration parameters. In some embodiments, the configurator 326 uses a machine learning model (e.g., an edge-transformed machine learning model trained on historical configurations of similar equipment units) to determine the configuration. In some embodiments, the configurator 326 interoperates with the cloud manager 340 to determine the configuration in a hybrid cloud / edge manner, for example, the configurator 326 and the cloud manager 340 determine different subsets of the configuration parameters. In some embodiments, the configurator 326 and / or the cloud manager 340 (e.g., in coordination with the user interface console 342) perform operations for automatic configuration as described in U.S. Patent No. 11,272,011, filed May 19, 2021, the entire disclosure of which is incorporated herein by reference.

[0053] like Figure 3 As shown, the analysis layer 302 is docked, allowing various applications 338 and product applications 336 (as well as analytical expressions, machine learning models, etc.) to be added to or removed from the analysis layer 302 in a modular fashion, for example, via over-the-air updates. For example, applications 338 and product applications 336 may include various control logics for device unit 106. Applications 338 and product applications 336 may also include various other programs, analyses, metric calculators, visualization generators, etc., that implement the various capabilities of device unit 106.

[0054] Edge circuit system 108 is further shown as including data publishing layer 304. Data publishing layer 304 includes cloud connector 323 and CEG HW 339. Cloud connector 323 is configured to provide a bridge between edge circuit system 108 (e.g., data bus 310) and cloud layer 102 (e.g., cloud processing portion 308), as described, for example, in U.S. Provisional Patent Application No. 63 / 296,078, filed January 3, 2022, the entire disclosure of which is incorporated herein by reference. CEG HW 339 provides data updates to and from cloud layer 102, for example, via SDK 334.

[0055] The cloud processing portion 308 of the cloud layer is shown as including an event processor 346, a message pipeline / storage device 348, and an enterprise application 350. The event processor 346 can be configured to receive and analyze data output from the edge circuitry system 108 and store such output. The event processor 346 can also be configured to perform additional (e.g., higher-level) analysis and processing on such information to generate additional insights and actionable steps or recommendations related to device unit 106. The message pipeline / storage device 348 provides communication between the event processor 346 and the enterprise application 350. The enterprise application 350 may include various cloud-based capabilities associated with managing, tracking, and / or influencing the operation of device unit 106 and, in some scenarios, other building equipment that may communicate with the cloud layer 102. For example, the enterprise application 350 may provide a distributor dashboard that enables comparison of device performance, events, etc., across many device units, different facilities, different customers, different device owners, different technicians or sales representatives, etc. As another example, enterprise application 350 may provide a user interface (e.g., via a mobile application, via a webpage hosted by enterprise application 350, etc.) that enables a user to view device unit 106 (e.g., as...). Figure 5 (as shown and referred to below in its description) or as... Figures 6 to 7 The diagram shows a group of devices experiencing events, malfunctions, etc.

[0056] Now for reference Figure 4 The diagram illustrates a view of an interface 400 that provides a user interface console 342 according to some embodiments. In the example shown, the interface 400 provided by the user interface console 342 is hosted by the analytics management portion 306 of a cloud system and is shown as a webpage accessed and displayed on a personal computing device (e.g., a laptop computer, desktop computer, etc.). In some embodiments, the interface 400 is positioned on a unified pane 116.

[0057] Interface 400 includes a menu 402 that includes buttons that allow a user to navigate to edge devices (e.g., edge circuit system 108) within a set of possible edge devices (e.g., multiple edge devices for a building site or portfolio) that can be managed by analytics management section 306. Menu 402 may include filtering and search features. In some embodiments, multiple edge devices (e.g., all edge devices of a selected device type) can be selected and managed together.

[0058] Interface 400 also includes a tab bar 404. Tab bar 404 allows users to select and view different information and manageable characteristics for a chosen edge device. As shown, tab bar 404 includes selectable tabs for health, status, edge details, and solutions that display information about the edge device. Tab bar 404 also lists sensors, analytics, edge machine learning (ML), applications, and data publishing, which can correspond to views providing customizable / manageable characteristics of the device. In the example shown, the analytics tab 406 is selected from tab bar 404.

[0059] The Analysis tab 406 is shown as including a list 408 of analyses (and / or other operations) that can be performed by the edge device. As shown, analyses may include, for example, data ingestion and tagging features that can be performed by the data ingestion layer 300 of the edge circuit system 108. Analysis is also shown as including alarms and event handling, which can be performed by the analysis engine 332 of the edge circuit system 108 using expression-based programming (e.g., setpoint incremental transformations and expression-based alarm procedures). The Analysis tab 406 also includes a column 410 indicating whether each item on list 408 is enabled on the edge device (as shown, all listed items are enabled).

[0060] The Analysis tab 406 also includes an Add button 412. The Add button 412 can be selected to add one or more additional analyses. The added analyses can be, for example, pre-programmed expressions in an expression-based language, thereby allowing the user to choose from expression-based logic created and validated by a set of experts. Analyses can also be user-created, for example, via an Expression Language Studio interface accessible by selecting the Start button 414 of the Analysis tab 406. In some examples, the Studio interface can provide an intuitive experience for creating logic in an expression-based language for execution by the edge circuit system 108, without requiring software programming expertise. For example, interface 400 can provide a development environment and programming language as described in U.S. Patent Application No. 10,977,010, filed April 21, 2020, the entire disclosure of which is incorporated herein by reference.

[0061] The Analysis tab 406 thus provides the user with the option to remotely select, deselect, and customize the logic to be executed by the edge circuit system 108. Therefore, the logic executed by the edge circuit system 108 can be easily modified and updated remotely via the cloud manager 340. In some embodiments, the Analysis tab 406 can be used to update multiple instances of the edge circuit system 108 simultaneously (e.g., multiple units simultaneously with devices installed at one or more facilities), thereby enabling over-the-air customization of a group of device units.

[0062] Now for reference Figure 5 An event interface 500 according to some embodiments is illustrated. For example, the event interface 500 may be located on a unified pane 116. The event interface provides a list of events occurring for a specific building or space. As shown, the event interface 500 displays a list of events locally detected at device unit 106 by an edge circuit system 108 that performs expression-based pattern recognition logic activated via interface 400. The edge circuit system 108 can determine the occurrence of such events locally and provide information indicating the occurrence of the events to cloud 102 without uploading all the data required to detect such events to cloud 102. For example, such an architecture can save bandwidth and cloud storage requirements. The event interface can then provide a list 502 of such events and a detail area 504 that shows further details (e.g., timestamp, event type, relevance point, etc.) of the contextual data of the event notification provided from the edge circuit system 108. Event data can also be provided in various other interfaces of the building automation system, such as integrated with building performance data and options for remote control of building equipment.

[0063] Now for reference Figures 6 to 7 This illustrates a dashboard, according to some embodiments, for viewing data for a group of device units (e.g., data provided from an edge circuitry system of said group of device units). For example, Figure 6 The dashboard 1800 and Figure 7 The dashboard 2000 can be positioned on the unified pane 116. For example, dashboards 1800 and 2000 can be provided as such. Figure 3 This is part of the enterprise application 350 shown. Advantageously, the dashboard provides aggregated data for multiple equipment units used at different building sites, and in some examples, equipment units owned or leased by different customers or building owners. The dashboard thus enables service branches, distributors, sales representatives, technicians, manufacturer experts, etc., to examine performance across customers and sites, identify trends or profiles, determine regions or customers for updates, upgrades, maintenance, etc., and otherwise more easily manage large groups of building equipment.

[0064] For details, please refer to the following: Figure 6 The diagram illustrates a dashboard 1800 according to some embodiments. The dashboard 1800 shows a monthly comparison widget 1802, a country chart widget 1804, a map widget 1806, a branch office widget 1808, a country selection widget 1810, and a month selection widget 1812, which are arranged to be displayed simultaneously on the user device's display screen (e.g., via a unified pane 116).

[0065] The monthly comparison widget 1802 displays the total number of active units (e.g., rooftop units, chillers, other types of equipment) with performance scores (shown as less than 50) below a threshold (shown as a connected device performance index, as described in U.S. Patent No. 11,092,954, filed January 10, 2019, the entire disclosure of which is incorporated herein by reference). In some examples, for instance, expression-based analytics and / or machine learning algorithms are used to calculate the performance score locally on each unit of the equipment. Performance scores below the threshold can be considered poor performance, requiring control adjustments, maintenance, or otherwise requiring intervention. The monthly comparison widget 1802 can process the aggregated data from step 1704 and count the number of different devices with scores below the threshold associated with the connected device performance index for that month for each monthly period, and then display these totals as shown below the threshold. Figure 6 The bar chart shown is used to generate the monthly comparison widget 1802. This widget can show the user how a group of connected devices are performing over time (e.g., as shown in the image). Figure 6 As in the example, there is a general trend of (monthly) demotion (increasing the number of underperforming units) and / or how they are being served or improved (reducing the number of underperforming units) over a two-year period.

[0066] The Country Widget 1804 displays a bar chart showing the performance index of connected devices associated with each of several countries. Other geographical distinctions include, in other examples, communities, campuses, cities, counties, states, etc. For example, the value for each country could be the average of all performance scores for all units of connected devices in that particular country (or, in other embodiments, the median, etc.). The Country Widget 1804 can arrange countries in order from worst (e.g., lowest) score to best (e.g., highest) score, making it easy for users to see which regions have the worst-performing connected devices. Although this example shows scores by country, other geographical classifications (states, territories, counties, states, regions, cities, communities, campuses, etc.) can be used in various embodiments. The Country Widget 1804 allows users to determine where to focus their attention for improvements, maintenance, and other interventions.

[0067] Map widget 1806 displays data similar to that of country widget 1804, which is visualized in a map view. Specifically, map widget 1806 displays a map (shown as a world map, but in other embodiments may be a map of a smaller region) on which data is visualized to show performance index values ​​for connected devices for different geographic regions shown on the map. In the example shown, each country where the connected devices are located is represented by a circle (e.g., colored and / or shaded circles) whose size and / or coloring are based on the average aggregate performance score or other aggregate performance score associated with that country. In some embodiments, larger circles indicate better scores, while smaller circles indicate lower scores (or vice versa in other embodiments). In some embodiments, each country has a circle whose size is based on the number of connected device units located in that country, and the circles are colored based on performance index values ​​(e.g., green for good / high values, yellow for medium values, and red for poor / low values). Thus, map widget 1806 displays a graphical view of device performance across geographic regions.

[0068] Branch office widget 1808 displays a graph showing the performance scores (e.g., connected device performance indexes) of sets associated with connected devices for different branch offices (i.e., different business units, departments, subgroups, subsidiaries, customers, service technicians, sales representatives, etc.). Figure 6 As shown, the branch office widget 1808 displays bar charts that are for each distinct branch office or at least for a subset of all distinct branches included in a given scenario (e.g., for branches with the five worst scores). The branch office widget 1808 can sort the charts such that the worst-performing branches (i.e., those with the worst / lowest scores) are shown first, thereby allowing users to easily see, based on the aggregated data visualized on dashboard 1800, the branches requiring the most intervention, attention, maintenance, investment, etc.

[0069] Country selection widget 1810 and month selection widget 1812 are configured to allow users to reduce the amount of data displayed on dashboard 1800. Month selection widget 1810 allows the user to select the month or subset of months for which dashboard 1800 will display data and visualizations. For example, if a user selects several months from a set of available months, month comparison widget 1802, country chart widget 1804, map widget 1806, and branch widget 1808 will be updated so that month comparison widget 1802, country chart widget 1804, map widget 1806, and branch widget 1808 visualize data for the selected months. In various embodiments, other time periods (year, season, day of the week, specific date, part of the day, hour, etc.) can be selected in the same manner.

[0070] The country selection widget 1810 provides a button for each country included in the data and allows the user to select the country on dashboard 1800 from which they wish the data to be displayed. In other embodiments, other types of geographic regions (regions, states, territories, counties, cities, etc.) may be similarly selectable. In the example shown, if the user selects a subset of countries, the monthly comparison widget 1802, country chart widget 1804, map widget 1806, and branch widget 1808 will be updated, making the monthly comparison widget 1802, country chart widget 1804, map widget 1806, and branch widget 1808 visualize the data for the selected countries.

[0071] Now for reference Figure 7 The dashboard 2000 displays device group data, specifically including visualizations of data from a selected one-month time period. This allows users to... Figure 6 Navigate from dashboard 1800 to dashboard 2000. Dashboard 2000 includes the average score widget 2002, the index bucket widget 2004, the timeline widget 2006, the event widget 2008, the field selection widget 2010, and the score filter widget 2012.

[0072] The average score widget 2002 is configured to display the average performance score for a subset of data represented in the selected (filtered) dataset. The index bucket widget 2004 displays the number and occurrence of faults corresponding to different ranges (displayed as greater than 75, between 50 and 75, and less than 50) of device performance scores. Faults, performance scores, etc., can be calculated at the edge and subsequently aggregated at the cloud for display via dashboard 2000, thereby reducing bandwidth requirements on network communications and resource demands on the cloud system, which would exist in an embodiment where all data is uploaded to the cloud and processed there to identify faults and calculate performance scores.

[0073] The Timeline widget 2006 is configured to display bar graphs showing the performance scores of connected devices for each day of a selected month, arranged spatially in chronological order. The bar graphs are overlaid with bars indicating the average penalty value for each day. The Timeline widget 2006 thus displays the performance score and penalty value for each day, allowing users to easily and quickly see any trends occurring over the selected month.

[0074] The Event Widget 2008 is configured to display events (or events meeting other filtering criteria) that occur within a selected month and are relevant to the connected device. Events may include detected faults, alarms, or other significant conditions or events related to the connected device. For example, the Event Widget 2008 may list the date, entity, facility, specific device asset, model, serial number, penalty value, penalty type, and description for each event. For instance, events may be determined at the edge by the device using event processing based on complex expressions.

[0075] The Field Selection widget 2010 is configured to present a list of categories from which users can select specific filters to further apply to the data used to generate Dashboard 2000. For example, Field Selection widget 2010 is displayed as including a list of customers (allowing selection of one or more customers or other entities), a list of facilities (allowing selection of one or more specific facilities), and a list of asset names (allowing selection of specific equipment assets). Once one or more additional fields are selected by the user via Field Selection widget 2010, Dashboard 2000 updates so that widgets 2002 through 2008 only visualize the data corresponding to the selected fields. This allows users to select the specific datasets they wish to visualize on Dashboard 2000.

[0076] The score filter widget 2012 is configured to accept requests to update the dashboard 2000 to visualize only the data corresponding to performance scores within a user-selectable range. Figure 7 A score filter widget 2012 is shown, configured to display scores between 0 and 100, where the upper and lower limits can be adjusted via numeric input or by numeric manipulation of a slider feature. For example, if the user resets the range shown in score filter widget 2012 to scores between 30 and 70, widgets 2002 through 2008 will be updated to display only the data corresponding to such data points. As an example, event widget 2008 will be updated to display only events that occur when performance is scored within the selected range. Dashboard 2000 thus implements yet another way to categorize and filter the displayed data.

[0077] Dashboards 1800 and 2000 thus provide various ways to visualize and understand pre-existing performance information from building equipment units distributed across buildings, geographical locations, end users, technicians, etc. Such dashboards can be seamlessly enabled by performing advanced event processing and performance scoring on each equipment unit at the edge, and then aggregating this higher-level information at cloud 102 for display to the user. Therefore, this disclosure enables the efficient and reliable presentation of Dashboards 1800 and 2000 with little or no manual configuration.

[0078] Edge devices with controller health app

[0079] Now for reference Figure 8 The diagram illustrates a system 800 according to some embodiments. System 800 may be part of a building automation system 100, for example... Figure 3 The specific implementation of the system shown is illustrated. System 800 is shown as including edge device 108 and cloud 102, which can be configured as described above, while additionally or alternatively including... Figure 8 The features shown and described in the following paragraphs.

[0080] like Figure 8 As shown, edge device 108 provides a data bus 310 and a cloud connector 323, wherein the data bus can exchange data with devices and sensors 801 at the building site (and / or other data sources), while the cloud connector 323 facilitates connectivity between edge device 108 and cloud 102, for example, as referenced above. Figure 3 The data bus 310 and cloud connector 323 shown are described.

[0081] Edge device 108 is also shown providing a control application (“application”) 802 and an analytics application 804 connected to data bus 310, such that the control application 802 and analytics application 804 can be executed by exchanging data with data bus 310. Control application 802 may include one or more containerized or docked control programs (control logic, control routines, etc.) for generating control outputs for device and sensor 801, for example, based on data from data bus 310. Analytics application 804 may include one or more containerized or docked programs for providing advanced processing, analysis, measurement, monitoring decision-making, report generation, or other desired operations. Control application 802 and analytics application 804 may be specific implementations of application 338, product application 336, and / or analytics engine 322, and include features described above. For example, in some embodiments, one or more control applications 802 and / or analytics applications 804 use edge adaptive machine learning models or other artificial intelligence algorithms executed locally on edge device 108, for example, in a containerized or docked manner using data from data bus 310 and providing data to that data bus.

[0082] Edge device 108 is also shown as including local storage for application 806. The local storage for application 806 on edge device 108 may include one or more computer-readable media for storing data, instructions, models, records, data bundles, status information, etc., such as data that may be adapted to support the execution of control application 802, analysis application 804, or other functions of edge device 108 (e.g., operations associated with container health application 808 described below) via data locally stored on edge device 108.

[0083] Edge device 108 is also shown as providing a controller health application 808 that communicates with data bus 310. Controller health application 808 includes a monitoring application 810, a diagnostic application 812, a self-healing application 814, and a bundled reporting application 816. These applications can be provided as separate docked or containerized applications, as a unified application within a container, and / or any combination of combined and separate applications. Controller health application 808 is configured to mount edge device 108 at the edge, monitor the operation of edge device 108, detect and diagnose problems in the operation of edge device 108, execute self-healing routines to resolve problems in the operation of edge device 108, and generate bundled records of relevant data for reporting problems and solutions (e.g., to a user).

[0084] Monitoring application 810 is configured to monitor data exchanged on data bus 310 with and streamed by various other applications (e.g., by control application 802 and analysis application 804). Monitoring application 810 can use one or more rule-based or artificial intelligence methods to detect problems reflected in such data, such as lost connectivity between endpoints of the data, data anomalies, performance degradation, error triggering, missing data sources, or other problems detectable via data on data bus 310. For example, in some embodiments, monitoring application 810 can perform actions such as... Figures 9 to 10 The process and / or use shown are as follows Figure 11The logic shown provides checks on network and endpoint connectivity. In various embodiments, problems monitored by the monitoring application 810 and detectable by the monitoring application may include connectivity problems (e.g., connectivity failures to remote servers, serial communication problems to networked devices, WiFi-related problems, Ethernet-related problems, cloud service problems such as network security operations including firewall or airwall operations, local domain name service errors, network adapter failures), application problems (e.g., software failures, critical logs / traces, critical system events, MSTP errors, conflicts, crash dumps, application health), device computing performance and load problems (e.g., CPU usage, memory usage, disk usage, system load, capacity problems, timeouts, denial-of-service attack detection, etc.), security-related problems (e.g., irregular number of login requests, irregular network traffic, unnecessary pings, network security-related incidents), and / or various other performance and health-related categories (e.g., various problems detectable through artificial intelligence monitoring of device parameters).

[0085] In response to a detected problem, monitoring application 810 may provide indications of such detection to other applications (e.g., to diagnostic application 812, self-healing application 814, and bundled reporting application 816), and may store problem-related information in local storage for application 806. For example, monitoring application 810 may initiate the collection of data (e.g., relevant data points, kernel and application system traces, logs, fault lists, configuration data (e.g., non-sensitive configurations), such as network configurations, status, system profiles, device models, traces, etc.) as this may be relevant to various problems detectable by monitoring application 810.

[0086] The diagnostic application 812 is configured to diagnose problems identified by the monitoring application 810, such as identifying the type of problem, the cause of the problem, the application or container responsible for the problem, or otherwise diagnosing one or more characteristics of the problem identified by the monitoring application 810. The diagnostic application 812 may perform its diagnostics using data from the monitoring application 810 and / or by exchanging data with the data bus 310 to receive information related to the operation of various applications (e.g., control application 802, analysis application 804), to query such applications or otherwise interact with such applications, or to retrieve information from local storage for application 806. In some embodiments, the diagnostic application 812 categorizes and scrolls a database of known problems that have occurred in the past (e.g., stored on local storage for application 806, or stored in cloud storage for application 818) to identify problems equivalent to the currently detected problem and / or to indicate various recovery actions taken in the past.

[0087] In some embodiments, the diagnostic application 812 uses at least one artificial intelligence model, such as an edge-classification model adapted to categorize the types of problems identified by the monitoring application 810 using various problem-related data exchanged with the data bus 310, or solutions to the problems. This at least one artificial intelligence model can be trained or fine-tuned at a local edge on the edge device 108 to improve accuracy for a specific edge device 108, for example, based on data stored in local storage for application 806 and / or bundled by the bundled reporting application 816, as described below. The diagnostic application 812 can thus output a diagnosis of the problem, such as the cause of the problem, the type of problem, and / or solutions or other steps to be taken in response to the problem.

[0088] The self-healing application 814 is configured to execute a self-healing routine for the edge device 108, for example, in response to the detection of a problem by the monitoring application 810 and / or the diagnosis of a problem by the diagnostic application 812. In some embodiments, the self-healing routine may include a storage-based algorithm to automatically identify trigger points to initiate a system recovery process (e.g., a point to which automatic recovery is initiated) and / or use various artificial intelligence methods to select (e.g., via a classification model) or artificially generate (using a generative AI model such as a large language model) one or more other actions to attempt to resolve the detected problem.

[0089] In some embodiments, the self-healing application 814 uses at least one artificial intelligence model (e.g., generative artificial intelligence) configured to infer the most effective solution from a set of past solutions attempted by the edge device and / or other edge devices experiencing similar problems. In some such embodiments, the self-healing application 814 uses data stored on local storage for application 806 or cloud storage for application 818 when evaluating such multiple sets of past solutions. In such embodiments, the dataset of past solutions may be stored locally on edge device 108 and / or in cloud 102, for example, dynamically moved between cloud 102 and edge device 108 to adaptively facilitate the operation of the self-healing application 814. In some embodiments, system 800 uses generative artificial intelligence (e.g., in cloud 102) to manage the identification and flow of successful solutions across edge devices for use by self-healing applications on various edge devices 108 within an enterprise system.

[0090] The self-healing routine may then include performing such actions, for example, by restarting or restoring edge device 108 or a portion thereof (e.g., an individual application, a specific container, an aspect of data bus 310, cloud connector 323) and / or otherwise reconfiguring the settings, parameters, network configurations, or other attributes of edge device 108 or a portion thereof (e.g., an individual application, a specific container, an aspect of data bus 310, cloud connector 323). While performing and completing the self-healing action, self-healing application 814 (e.g., together with monitoring application 810 and diagnostic application 812) may check whether the identified problem has been resolved, or whether self-healing application 814 should execute a different solution to resolve the problem (in which case, such a solution may be executed by self-healing application 814). Therefore, self-healing application 814 is operable until the problem is resolved or it is determined that the identified problem cannot be self-healed locally by edge device 108.

[0091] The bundled reporting application 816 is configured to collect and bundle data records related to problems identified by the monitoring application 810, diagnosed by the diagnostic application 812, and / or repaired by the self-healing application 814. For example, the bundled reporting application 816 may bundle in records relevant data that caused the monitoring application 810 to detect the problem and / or otherwise begin from the time the problem was detected (e.g., various data on the data bus 310 at the time the problem occurred); data related to triggering conditions, rules, models, algorithms, etc., used to identify and / or diagnose the problem; data related to one or more self-healing actions or solutions attempted by the self-healing application 814; and the results of the self-healing actions or solutions (e.g., data reflecting relevant system performance after such actions were taken). In various embodiments, such data may include triggers, results, diagnoses, recovery actions, configuration data, device models, traces, network configurations, status, etc. Such data may exceed datasets that would otherwise be saved in scenarios where no problem was detected, and may include data that might be automatically deleted or otherwise removed from memory or the data bus without being retained if no problem was detected.

[0092] In some embodiments, the bundled reporting application 816 is configured, for example, via commands provided on the data bus 310, to cause additional data to be provided to the application, device, and / or sensor. For example, the bundled reporting application 816 may cause the camera or other sensor of the device and sensor 801 to provide additional data (e.g., streaming video feeds, still images at a higher frequency under standard operation in the absence of a detected problem) to the data bus 310 (e.g., more data than would otherwise be provided in the absence of a detected problem).

[0093] Various types of such data can be collected as problem-related bundles and stored on local storage for application 806 and / or uploaded as bundles (e.g., in batches) to cloud 102 (e.g., cloud storage for application 818), for example, when network bandwidth and connectivity permit and / or when a user request is received at edge device 108 (e.g., via a user interface interacting with cloud 102) via cloud connector 323. The bundled reporting application 816 can thus collect more robust problem-related data records than would be provided without the teachings of this document, for example, enabling improved operation of the controller health application (e.g., via reinforcement learning) and / or improving the visibility of users or remote systems and algorithms to the situation surrounding the problem occurring at edge device 108.

[0094] In some embodiments, bundled data is used to train artificial intelligence (e.g., machine learning) models to improve detection and remediation. For example, in some embodiments, cloud manager 342 of cloud layer 102 provides cloud-based training of such AI models, such as reinforcement learning on a model deployed in controller health application 808 based on bundled data, so that the model improves over time as controller health application 808 detects and resolves problems. Such updated / improved models can be trained in a format suitable for training in the cloud and subsequently repackaged in an edge-adapted (“edge-oriented”) form for efficient execution on edge device 108 and provided as over-the-air updates to controller health application 808 for local execution on edge device 108. In various embodiments, various other adjustments, user management, training, logic selections, etc., can be made via cloud manager 342 to influence the operation of controller health application 808.

[0095] In some embodiments, cloud layer 102 provides a graphical user interface (e.g., via a web browser) to a user computing device (e.g., a laptop computer, desktop computer, smartphone, etc.), providing access to bundled data, for example, via cloud storage for application 818 and / or cloud manager 342. In some embodiments, cloud layer 102 uses large language models or other generative artificial intelligence techniques to automatically generate summaries of reports of bundled record data from bundled reporting application 816, such as summaries in natural language describing what happened at edge device 108 as reflected in the bundled record data (e.g., what happened, how the problem was detected, how it self-healed). Therefore, the teachings herein can provide users with visibility into the self-monitoring and self-healing activities of edge device 108.

[0096] Advantageously, by proactively monitoring and self-healing device performance locally at the edge, through exchanging data via a common data bus also used by various other containerized applications (e.g., control application 802 and analytics application 804) and capable of communicating with devices and sensors 801, performance issues can be detected and resolved in real time, even under conditions where cloud connectivity may be intermittent, unavailable, or bandwidth-constrained. This approach improves edge device reliability and resolves issues much faster than methods requiring users to manually observe problems and report them to customer service before a solution can be initiated. Given that the edge device 108 is envisioned as controlling physical devices (such as heating and cooling equipment for buildings and / or other industrial equipment) that should operate substantially continuously and appropriately to control environmental conditions, etc., such advantages may be particularly important in the context of this application.

[0097] Now for reference Figures 9 to 10 The diagram illustrates a process 900, according to some embodiments, including a process executable by a controller health application 808 (e.g., ...). Figure 9 (as shown) and process 1000 (as shown) Figure 10 The flowchart of the technology shown is shown. Processes 900 and 1000 can be executed together as described below to provide automated detection, resolution, and reporting of endpoint connectivity problems of edge controllers such as edge device 108.

[0098] At step 902, connectivity of known endpoints is checked. Endpoints may include network locations outside edge device 108 (e.g., devices, other controllers, building automation system devices, clouds, sensors, etc.) and / or endpoints of edge device 108 (e.g., endpoints within various containerized applications of edge device 108). It is determined (box 904) whether all endpoints checked in step 902 are accessible. If yes, it is determined (box 906) whether a problem occurred in a previous iteration of the executed process 900. If not, process 908 proceeds to step 908, where process 900 waits for an interval (e.g., a set time period) before returning to step 902 to restart process 900. If a problem did occur during the previous iteration (yes at box 906), it is determined whether a problem has been reported (box 910). If a problem that occurred during the previous iteration has been reported (yes at box 910), process 900 proceeds directly to step 908 to wait for another iteration to be initiated. If a problem that occurred during a previous iteration has not been reported (No at box 910), then at step 912, the error is reported to the reporting endpoint along with an indication that the problem has been resolved. After such a report in step 912, process 900 may continue to wait for a period of time at step 908, and then restart another iteration at step 902.

[0099] If, based on the connectivity check of the endpoints in step 902, it is determined that not all endpoints are accessible ("No" from box 904), then process 900 proceeds to determine (at box 916) whether some endpoints are accessible (i.e., whether a subset of endpoints are accessible, or whether all checked endpoints are inaccessible). If no checked endpoints are accessible (all such endpoints are inaccessible) ("No" at box 916), then process 900 proceeds to step 914, where network connectivity is checked, for example, by automatically checking for cable disconnections or internet outages, or otherwise checking for network connectivity problems. If a network connectivity problem is determined ("Yes" at step 918), then process 900 proceeds to step 920, where it is determined whether the network connectivity problem has been recorded (box 920). If a network connectivity problem has not yet been recorded ("No" at box 920), a network outage is recorded in step 922, and the problem is determined to be outside the edge device. Then, process 900 waits for a period of time in step 908 before starting another iteration. If a network connectivity problem has already been recorded ("Yes" at box 920), process 900 proceeds from box 920 to waiting for a period of time in step 908 before starting another iteration.

[0100] If some endpoints are accessible (Yes at box 916) or there are no network connectivity issues (No at box 918), then determine (box 924) whether an endpoint inaccessibility issue has been logged. If an endpoint inaccessibility issue has been logged (Yes at box 924), then process 900 may wait for a period of time at step 908 before starting another iteration. If an endpoint inaccessibility issue has not been logged (No at box 924), then process 900 may initiate process 1000 to diagnose and attempt to correct the endpoint inaccessibility issue, as referenced below. Figure 10 As described.

[0101] like Figure 10 As shown, process 1000 can be initiated at step 1002 after process 900, as follows: Figure 9 and Figure 10 The process of traveling to and from point "A" is illustrated. At step 1002, records are collected from applications using inaccessible endpoints (e.g., docked or containerized applications on a data bus). For example, both control application 802 and analysis application 804 may use the same endpoint (e.g., sensor point, device unit, etc.) for control and / or analysis operations, such that step 1002 may include obtaining records from both the relevant control application 802 and analysis application 804. Such records can provide information related to the interaction between such applications and the relevant endpoints, and may provide data associated with, for example, the last known interaction with the endpoint, actions taken by the application that may affect the endpoint's accessibility, application software errors within the application that may affect the endpoint's accessibility, etc. At step 1004, network profiles are collected and commands are run to obtain network information. Step 1004 may include generating data related to network availability, network configuration, network address, network bandwidth, etc., which may be related to endpoint accessibility, even if no general network connectivity issues are found in step 914.

[0102] At step 1006, conditions surrounding the unavailable endpoint are evaluated. For example, records and network files collected in steps 1002 and 1004, along with information, may be evaluated in step 1006. Step 1006 may include applying such conditions as input to at least one artificial intelligence model trained to diagnose problems causing endpoint unavailability, identify corrective actions to be taken, and / or identify scenarios where insufficient information is available to take corrective actions. Such techniques in step 1006 can be used to determine (in box 1008) whether sufficient information is available to take corrective actions (e.g., whether sufficient information is available to the artificial intelligence model to identify corrective actions expected to resolve the endpoint unavailability problem).

[0103] If sufficient information is available to take a corrective action ("Yes" at step 1010), process 1000 proceeds to step 1010, where a corrective action is taken and the action is recorded. In various embodiments, the corrective action may include restarting the system network or airwall network (e.g., network security protocols and components) and / or otherwise performing corrections on the network, endpoint devices (e.g., by providing commands to devices or sensors to restart or reconfigure), programs on edge devices (e.g., adjusting parameters used by applications interacting with the endpoints), etc. Such actions may be performed locally by edge device 108 to implement the corrective action.

[0104] Following such a corrective action in step 1010, or if insufficient information is available to take a corrective action (No at box 1008), it is determined whether the endpoint is now accessible (box 1012). For example, endpoint accessibility can be checked in a manner similar to that in step 902, where some endpoints may now have been restored to accessibility through the corrective action. If some endpoints remain inaccessible (No at box 1012), the remaining errors are reported to the reporting endpoint at box 1014. Following box 1014, or if all checked endpoints are now accessible (Yes at box 1012), process 1000 can flow back to process 900 (as in...). Figure 9 and Figure 10 As indicated by point "B" in the diagram, a period of time is waited at step 908 before starting another iteration of process 900. Therefore, processes 900 and 1000 are combined to monitor endpoint accessibility, report endpoint accessibility issues, and, where feasible (e.g., if it is automatically determined that a network error is not associated with the control of edge device 108, and if sufficient information exists to identify and take corrective actions to resolve endpoint accessibility issues), attempt to resolve endpoint accessibility issues locally and automatically at the edge.

[0105] Now for reference Figure 11 This illustrates logic 1100 for monitoring and detecting connectivity problems via data bus 310, which can be implemented, for example, by a monitoring application 810, for the monitoring application, within the monitoring application, or in parallel with the monitoring application. Figure 11As shown, the socat command 1102 is used to check whether a connection is maintained between two endpoints, such as between two containerized applications or between an endpoint outside of edge device 108 and an application provided by edge device 108. The socat command 1102 may provide this functionality via interaction with ttymxc1 box 1104 and ttyTIA485-0 box 1106, which may involve the availability of a serial port and cable connections to such a serial port. Logic 1100 may include a running logger 1108, such as a Python-coded logger, which can record data from data bus 310 and provide connectivity with the socat command 1102 to enable data logging activity related to monitoring and detecting connectivity issues for the edge device, as an example feature that can be used in conjunction with the various teachings herein.

[0106] Although Figures 9 to 11 This paper demonstrates a sequence of steps for monitoring, inspecting, diagnosing, and resolving specific problems that may occur on edge devices. However, the teachings presented herein are not limited to such methods and can be adapted to address a wide range of problems and solutions. For example, as discussed above, artificial intelligence models can be used to infer the most effective solution from a set of potential solutions based on autonomous analysis of currently detected problems and similar problems that have occurred in the past (on the same edge device, or in some embodiments, on other edge devices), for example, by following dynamic adaptive AI-driven techniques rather than prescribed rule-based processes.

[0107] The hardware and data processing components described herein for implementing various processes, operations, illustrative logic, logic blocks, modules, and circuits can be implemented or performed by: a general-purpose single-chip or multi-chip processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor can be a microprocessor or any conventional processor, controller, microcontroller, or state machine. A processor can also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration. In some embodiments, specific processes and methods can be performed by a specific circuit system for a given function. Memory (e.g., memory, memory cell, storage device) can include one or more means (e.g., RAM, ROM, flash memory, hard disk storage device) for storing data and / or computer code to perform or facilitate the various processes, layers, and modules described herein. The memory may be or contain volatile or non-volatile memory, and may contain database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described herein. According to an exemplary embodiment, the memory is communicatively connected to a processor via processing circuitry and includes computer code for (e.g., by the processing circuitry or processor) performing one or more of the processes described herein.

[0108] This disclosure contemplates methods, systems, and program products on any machine-readable medium for performing various operations. Embodiments of this disclosure can be implemented using existing computer processors, or by special-purpose computer processors for suitable systems, combined for this or another purpose, or by hardwired systems. Embodiments within the scope of this disclosure include program products comprising machine-readable media for carrying or storing machine-executable instructions or data structures. Such machine-readable media can be any available medium accessible by a general-purpose or special-purpose computer or other machine having a processor. By way of example, such machine-readable media may include RAM, ROM, EPROM, EEPROM, or other optical disk storage devices, magnetic disk storage devices, or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of machine-executable instructions or data structures and accessible by a general-purpose or special-purpose computer or other machine having 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 that cause a general-purpose computer, special-purpose computer, or special-purpose processing machine to perform a function or group of functions.

[0109] Although the accompanying drawings and specifications may illustrate a specific order of method steps, such order may differ from the order depicted and described unless otherwise stated above. Furthermore, unless otherwise stated above, two or more steps may be performed simultaneously or partially simultaneously. Such variations may depend, for example, on the chosen software and hardware system and may depend on the designer's choice. All such variations are within the scope of this disclosure. Similarly, software implementations of the described methods can be implemented using standard programming techniques with rule-based logic and other logic for implementing various connection steps, processing steps, comparison steps, and decision steps.

Claims

1. An edge controller for building equipment, the edge controller comprising a circuit system programmed to provide: The data bus is located locally on the edge controller; Multiple containerized applications, which execute on the edge controller by exchanging data with the data bus; and A controller health application, which executes on the edge controller and monitors the health status of the plurality of containerized applications via the data bus.

2. The edge controller of claim 1, wherein the controller health application is configured to provide health monitoring via data records using at least a subset of the data exchanged between the plurality of containerized applications and the data bus.

3. The edge controller of claim 1, wherein the controller health application is configured to execute a self-healing routine for the edge controller in response to detecting a problem in at least a first application among the plurality of containerized applications.

4. The edge controller of claim 3, wherein the self-healing routine comprises: Use at least one artificial intelligence model to identify solutions to the problem; as well as The solution is implemented automatically at the edge controller.

5. The edge controller of claim 1, wherein the controller health application is configured to record additional data streaming on the data bus in response to detecting a problem in at least a first application among the plurality of containerized applications.

6. The edge controller of claim 5, wherein the controller health application is configured to record the additional data by saving the additional data to the edge controller's local data storage.

7. The edge controller of claim 5, wherein the circuitry includes a port coupled to the data bus to receive measurement results from a sensor and provide an output to the sensor, wherein a device health application is configured to provide the output to the sensor in response to detecting the problem, the output causing the sensor to stream the additional data to the data bus.

8. The edge controller of claim 6, wherein the sensor is a camera.

9. The edge controller of claim 5, wherein the circuitry is further programmed to provide a network connection to a remote server, wherein the device health application is configured to generate a packet including the additional data and provide the packet to the remote server via the network connection.

10. The edge controller of claim 1, wherein the controller health application is further configured to: Try to implement multiple solutions for multiple problems across multiple applications; Record the results of executing the multiple solutions to the multiple problems for the multiple applications; as well as The machine learning model of the controller health application is trained locally on the edge device to determine future solutions based on the records.

11. The edge controller of claim 1, wherein the controller health application is configured to: Check the connectivity of known endpoints; In response to a lack of connectivity at at least one of the endpoints, check the network connectivity; and In response to a combination of the network connection and the lack of connectivity of at least one of the endpoints: Records are collected from a subset of the endpoints used by the multiple containerized applications; and Corrective actions are taken based on the recorded information.

12. The edge controller of claim 1, wherein the controller health application is configured to monitor the streaming data when the edge controller abandons transmitting at least some of the streaming data on the data bus out of the edge controller.

13. A building management system, the building management system comprising: Equipment units that can be operated to heat, cool, or ventilate building spaces; Sensors configured to measure the condition of the building space; An edge controller, configured to receive measurements of the condition of the building space from the sensors and control the device unit, wherein the edge controller is further programmed to provide: A data bus, located locally on the edge controller, is configured to receive the measurement results from the sensor and enable control output to be provided to the device unit; Multiple containerized applications execute on the edge controller by exchanging data with the data bus, and at least one of the multiple containerized applications generates the control output based on the measurement results; as well as A controller health application, which executes on the edge controller and monitors the health status of the plurality of containerized applications via the data bus.

14. The building management system of claim 13, wherein the edge controller is located at the building site close to the device unit and the sensor.

15. The building management system of claim 14, wherein the controller health application is configured to: Health monitoring is provided by using data records of at least a subset of the data exchanged between the plurality of containerized applications and the data bus; and A self-healing routine for the edge controller is executed in response to the detection of a problem in at least the first of the plurality of containerized applications.

16. The building management system of claim 15, wherein the self-healing routine comprises: Use at least one artificial intelligence model to identify solutions to the problem; as well as The solution is implemented automatically at the edge controller.

17. The building management system of claim 13, wherein the controller health application is configured to check connectivity with one or more endpoints.

18. The building management system of claim 13, wherein the controller health application is configured to record additional data streaming on the data bus in response to detecting a problem in at least a first application among the plurality of containerized applications.

19. The building management system of claim 13, wherein the controller health application is configured to cause the sensor to provide the additional data to the data bus in response to detecting the problem.

20. The building management system of claim 13, wherein the sensor is a camera and the additional data is streaming video.

Images