Patent Application
20230096929
Electrically switchable glass, also known as electrochromic glass, may include a type of glass or glazing for which light transmission properties of the glass or glazing are altered when electrical power (e.g. voltage/current) is applied to the electrically switchable glass. For example, electrically-switchable glass may include suspended particles that are organized or that revert to a disorganized state based on the application of electrical power. Also, electrically-switchable glass may include electrochromic materials that change in opacity when electrical power is applied. Some electrochromic materials may maintain a level of opacity resulting from the application of an electrical voltage, even after the electrical voltage is no longer applied. Also, electrically-switchable glass may include polymer dispersed liquid crystals that may be ordered in an aligned configuration or a non-aligned configuration which causes light to be allowed or impeded from passing through the electrically switchable glass, wherein the alignment of the liquid crystals is controlled by applying electrical power to the material.
Controllers may control electrically switchable glass by controlling a voltage or current applied to the electrically switchable glass. In many systems different types and sizes of electrically-switchable glass may be used, and the different types and sizes of electrically switchable glass may require different levels of current and/or voltage to achieve similar levels of opacity. Thus, in systems comprising various sizes and types of electrically-switchable glass, configuration and control parameters for respective controllers that control different pieces of electrically switchable glass may need to take into account differences in characteristics of the electrically switchable glass (e.g. different required voltage levels or currents) to achieve particular opacity levels.
In addition, an on-premises control system at the installation site for the electrically switchable glass, also known as electrochromic glass, can take into account the time of day and sensor readings to determine the desired opacity for different panes of the electrically switchable glass. The on-premises control system can communicate with the controllers for the electrically switchable glass to set the opacity level of the glass taking into account the various parameters. The on-premises control system can take into account the orientation of the building and the side of the building the different panes of glass or electrochromic glass units (“EGUs”) are located.
For example, at sunrise, the sun's low position on the horizon means light shines directly on the east elevation, causing significant glare. An on-premises control system might set the east facade to tint fully, while the rest of the building remains clear for maximum daylight harvesting. At noon, as the sun passes overhead, the on-premises control system can tint to compensate. Glass on the east and south elevations can tint based on zoning strategies. The on-premises control system can, for example, call for intermediate tint states in certain zones to achieve specific light levels. In the late afternoon, intense afternoon heat, combined with direct sun, can create a need for thermal comfort control and energy savings. In this case, the on-premises control system can tint the glass to maximize occupant comfort and energy savings. At sunset, occupants seated near the west facade of the building are subject to glare as the sun begins to set. The on-premises control system can tint the windows on the west facade fully to block that direct angle glare.
However, the current on-premises control system does not provide any robust remote functionality, either by building occupants, or by the manufacturer. Building occupants would like the ability to control and monitor their electrochromic glass units from their mobile phones. Additionally, building occupants as well as the building owners want to know that their installation is being monitored by the manufacturer to ensure service continuity.
While embodiments are described herein by way of example for several embodiments and illustrative drawings, those skilled in the art will recognize that the embodiments are not limited to the embodiments or drawings described. It should be understood, that the drawings and detailed description thereto are not intended to limit embodiments to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope as defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or the claims. As used throughout this application, the word “may” is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must). The words “include,” “including,” and “includes” indicate open-ended relationships and therefore mean including, but not limited to. Similarly, the words “have,” “having,” and “has” also indicate open-ended relationships, and thus mean having, but not limited to. The terms “first,” “second,” “third,” and so forth as used herein are used as labels for nouns that they precede, and do not imply any type of ordering (e.g., spatial, temporal, logical, etc.) unless such an ordering is otherwise explicitly indicated.
“Based On.” As used herein, this term is used to describe one or more factors that affect a determination. This term does not foreclose additional factors that may affect a determination. That is, a determination may be solely based on those factors or based, at least in part, on those factors. Consider the phrase “determine A based on B.” While B may be a factor that affects the determination of A, such a phrase does not foreclose the determination of A from also being based on C. In other instances, A may be determined based solely on B.
The scope of the present disclosure includes any feature or combination of features disclosed herein (either explicitly or implicitly), or any generalization thereof, whether or not it mitigates any or all of the problems addressed herein. Accordingly, new claims may be formulated during prosecution of this application (or an application claiming priority thereto) to any such combination of features. In particular, with reference to the appended claims, features from dependent claims may be combined with those of the independent claims and features from respective independent claims may be combined in any appropriate manner and not merely in the specific combinations enumerated in the appended claims.
Various embodiments of systems and methods for long-term benchmarking for electrochromic glass are described herein. The systems and methods for long-term benchmarking for electrochromic glass can connect an EGU installation site to a remote device monitoring and control system that might be provided by a provider network, and can allow for near real-time communications to occur between the site and the remote system, in some embodiments. The device monitoring and control system can transmit control messages to respective communication gateways for a plurality of remote installation sites for EGUs to benchmark the state the EGUs at the respective installation sites, in some embodiments. During a low usage time of the EGUs, an installation site control system can collect telemetry data while cycling the state of its EGUs between clear and full tint to perform the benchmarking, in some embodiments. The device monitoring and control system can receive messages from the installation sites, where the messages comprise the telemetry data associated with the benchmarking of the EGUs, in some of these embodiments. The device monitoring and control system can store the telemetry data in data storage, perform analytics functions on the telemetry data at a data analytics engine, and provide results of the analytics functions to one or more remote destinations. Additionally, the telemetry data collected from the site can be directly streamed through analysis pipelines of the remote device monitoring and control system for anomaly detection, in some embodiments. Therefore, the disclosed systems and methods for long-term benchmarking for electrochromic glass can provide for remote application and control, as well as telemetry data collection and streaming, along with a real-time analytics and alerting, in some embodiments.
The systems and methods for long-term benchmarking for electrochromic glass can allow the remote device monitoring and control system to communicate with the installation site control system to perform benchmarking of EGUs, in some embodiments. The benchmarking can include driving certain EGUs from clear to full tint, in some embodiments, or simply from one tint level to another, in other embodiments. Other types of EGU control or simply analyzation of the telemetry of the EGUs without performing any specific control functions can also be implemented to perform the benchmarking, depending on the embodiment. The benchmarking can also include driving the EGUs from full tint back to clear, or from the previous ending tint level back to the previous starting tint level, or simply from the previous ending tint level to another ending tint level, depending on the embodiment. The changing of the tint of the EGU can then be sampled, in some embodiments. The sampling can be at a very high rate, in some of these embodiments. The benchmarking might be performed only one window at a time, in certain embodiments, in order to not overload the installation site control system.
The benchmarking of an EGU can be performed on a regular, sporadic, and/or periodic basis, such as nightly or weekly, in some embodiments. For example, the same test might be performed on the EGU at regular, sporadic, and/or periodic basis. When performed regularly, sporadically, and/or periodically over a long-term period of time, the EGU can be analyzed, and the performance of the EGU can be determined over this period of time. For example, an analysis of the benchmarking data might determine that the performance of the EGU has degraded over time. In addition, analytics can be performed on the benchmarking data over time. The performance of the EGU can be compared to the outside temperature and/or humidity over multiple benchmarking points in time, for example.
The control messages regarding the benchmarking can specify, in some embodiments, that the benchmarking occur during low usage times of the EGUs at the respective installation sites. For example, the benchmarking activities (such as cycling an EGU from clear to full tint) can be set to occur during the night. As another example, the benchmarking activities can be set to occur on a weekend, if the installation site has low occupancy during the weekend, for example, resulting in low usage of the EGUs. In some embodiments, the device monitoring and control system can communicate with the installation site control system to specify some of the parameters of the benchmarking and then the installation site control system can perform the benchmarking itself. In other embodiments, the device monitoring and control system can instruct the EGUs (either directly, or through the installation site control system as an intermediary, in some embodiments) to perform benchmarking activities (such as cycling the EGU from clear to full tint). In some of these embodiments, the device monitoring and control system might instruct the EGU to perform the benchmarking activity, and then request data regarding that EGU from the installation site control system.
The device monitoring and control system can also allow the users associated with an installation site to opt-in (or opt-out) the installation site to the benchmarking, in some embodiments. If the users opt-in, the device monitoring and control system can allow the users to specify a time for the benchmarking to occur, in some embodiments. The opt-in (or opt-out) messages can be communicated through a programmatic interface of the device monitoring and control system, in some embodiments. The device monitoring and control system can receive initial messages, in some embodiments (such as from the communication gateways for a plurality of installation sites, or using the programmatic interface of the device monitoring and control system, or both, or using a different communication mechanism, depending on the embodiment) wherein the initial messages can comprise an acceptance of the benchmarking for the respective installation sites, in some embodiments. The initial messages can also include a time or time interval for the benchmarking for the respective installation sites, in some embodiments. The time or time interval for the benchmarking for the respective installation sites can also be communicated separately, in some embodiments, and this communication can be through the programmatic interface, or from the communication gateway, or both, or using a different communication mechanism, depending on the embodiment. The device monitoring and control system can then transmit the control messages to benchmark the state of the at least some of the EGUs to only those installation sites from which the initial messages comprising the acceptance of the benchmarking were received, in some of these embodiments.
The systems and methods for long-term benchmarking for electrochromic glass can also optimize the payload size and minimize the number of transactions from an installation site to a remote device monitoring and control system, in some embodiments. Some embodiments can utilize a micro-batching process where many data points are written into a single IoT message that is sent to the remote device monitoring and control system. Once the message arrives at the remote device monitoring and control system, it can then be expanded and parsed into the individual data points, in some embodiments. These data points can then be stored, analyzed and reported, in some embodiments.
The systems and methods for long-term benchmarking for electrochromic glass provides remote access and accessibility to an installation site control system, at an installation site, that controls the EGUs of the installation site, in some embodiments. The installation site control system can take inputs from sensors, such as lighting sensors, and input devices such as wall touch panels. The systems and methods for long-term benchmarking for electrochromic glass allows remote access to the system as well as for remote data logging, in some embodiments. Previously, an installation site control system was a closed system that existed on a network within the building, but remote clients/users did not have access to the system, and there was no real easy methods for communicating with the on-site control infrastructure at a building. The systems and methods for long-term benchmarking for electrochromic glass provides the mechanisms for communicating with the on-site controls infrastructure, which will then ultimately tint the EGUs, in some embodiments.
The provided systems and methods for long-term benchmarking for electrochromic glass can allow for data collection of the installation site systems and components, as well, in some embodiments. The device monitoring and control system can capture electronic characteristics regarding the properties, behavior, and functioning of the electrochromic glass at multiple installation sites, in some embodiments. An installation site control system can collect telemetry data from sources, such as EGUs, by using Internet of Things (“IoT”) techniques and functions, in some embodiments. The installation site control system can stream the data back to the remote monitoring and control system (which might be hosted by a provider network) for analysis and monitoring, in some embodiments. The remote monitoring and control system can send alerts, for example, if a particular EGU is behaving poorly. These alerts can be sent to a user, such as a building occupant, a customer, such as a building owner, or the EGU manufacturer, such as a remote field support monitoring system and/or service operations center, in some embodiments.
The systems and methods for long-term benchmarking for electrochromic glass can allow the remote monitoring and control system to analyze telemetry data received for EGUs at various installation sites. It can then provide instructions to respective installation site control systems at one or more of the respective installation sites to change settings for one or more respective EGUs at the one or more respective installation sites. For example, if the remote monitoring and control system detects that the response curve of an EGU is changing over time, it can then adapt the control algorithm for that particular EGU to compensate for the changing response curve. As another example, the remote monitoring and control system can determine that the response characteristics of an EGU changes with changes in temperature and/or humidity. It can then adapt the control algorithm for that particular EGU for different temperature and humidity characteristics to compensate for the changing response curve at the different temperature and/or humidity points.
The systems and methods for long-term benchmarking for electrochromic glass can also allow the remote monitoring and control system to collect data from many different installation sites, either in a specific region or even around the world. The remote monitoring and control system can collect metadata of the EGUs at these many different installation sites, such as the direction one or more of the EGUs is facing, the time of day the data is taken for one or more EGUs, the size of the one or more EGUs, the temperature of the one or more EGUs, or the geolocation of one or more EGUs. The remote monitoring and control system can perform at a large scale, collect a vast amount of data, and analyze the vast amount of data using analytics. The remote monitoring and control system can search for patterns, either for individual EGUs or across installation sites. The remote monitoring and control system can search for patterns for similar products across multiple installation sites, for example. The remote monitoring and control system can search for patterns in data based on the collected metadata: such as the geolocation of the installation sites, the time of day the data is taken, the size of the EGUs, the temperature of the EGUs, or the direction the EGU is facing at various installation sites. The results of these analytics can be used as feed back to tune the control algorithm of EGUs either at one installation site or many different installation sites. For example, the data from the analytics of an installation site can be used to fine-tune control algorithms for other installation sites. As a further example, these other installation sites might be located in the same city or region, or on the same or similar longitude, depending on the embodiment. In addition, the results of these analytics can be used to improve manufacturing of the EGUs by the EGU manufacturer. There are many different uses for the results of the analytics, and these examples should not be construed as being limiting.
The provided systems and methods for long-term benchmarking for electrochromic glass can allow the installation sites to operate as closed system, without any communication, monitoring, or control from a remote device monitoring and control system, in some embodiments. The installation site control system can operate independently from any external device monitoring and control system, in these embodiments. The installation site control system can receive data from sensors at the installation site, whether they be sensors for the EGUs, or sensors external to a building, or sensors internal to a building, and can perform operations to provide tinting of the EGUs based on its preprogrammed settings, for example. The installation site control system can perform local monitoring and control, in these embodiments. However, in preferred embodiments, the provided systems and methods for long-term benchmarking for electrochromic glass can also allow the installation sites to operate as open systems, where they receive control from and provide data to a remote device monitoring and control system.
The provided systems and methods for long-term benchmarking for electrochromic glass can also provide real-time or near real-time analysis and reporting of data. While the disclosed device monitoring and control system can store data, such as in data lakes or databases, the data is not analyzed from the data storage systems, in some embodiments. Instead, the data in the device monitoring and control system can be constantly in transit, such that it can provide real-time analysis and reporting, in these embodiments. The device monitoring and control system can apply algorithms to streaming pipelines of data, where the data is data from an EGU installation site, in these embodiments. The data can be arriving to a data analysis engine as a stream, and the data analysis engine might look at a previous quantity of data to analyze and draw conclusions from, in some embodiments. For example, the data analysis engine might look at the last 15 minutes of data, and run its algorithms, analytics, and/or functions over the last 15 minutes of data constantly. The data analysis engine might also compare the streaming data, or a previous quantity of the streaming data, to previous data stored in data storage, in some embodiments.
The data analysis engine can, in some embodiments, compare telemetry data associated with the benchmarking of the state of the EGUs with previous stored telemetry data associated with the benchmarking of the state of the EGUs. When the data analysis engine acquires a signature from one of its algorithms, analytics, and/or functions it can provide an output to a destination, in some embodiments. This output can be, for example, an alert to a client, user and/or system administrator. For example, if the data analysis engine determines that the performance of an EGU has degraded past a threshold, then it might provide an alert to a remote destination regarding the EGU, based at least in part on the determination, in some embodiments. The data analysis engine can also, in some embodiments, provide access to the stored telemetry data for a particular installation site to the one or more destinations associated with the particular installation site, while preventing the one or more destinations associated with the particular installation site from accessing stored telemetry data for other installation.
An on-site control infrastructure, of the disclosed systems and methods for long-term benchmarking for electrochromic glass, can encompass many designs and configurations, depending on the embodiments. The on-site control infrastructure can include sensors, such as daylight sensors or sensors of the installed EGUs, in some embodiments. The on-site control infrastructure can also include a controller that is a direct interface to the EGUs, in some embodiments. The controller might provide electricity as well as control signals to the EGUs, for example. The on-site control infrastructure can also include some kind of control intelligence, in some embodiments. There can be multiple control intelligence modules, in some embodiments. In some embodiments, one of these modules can be a master control intelligence module that provides management and/or control of the other control intelligence modules. The control intelligence modules/components might be a System Integration Module (“SIM”) in some embodiments. A SIM can be a Linux-based single board computer that provides system level control of the entire on-site control system, in some embodiments. A SIM can be housed in a Control Panel, in some embodiments. The control intelligence, such as a SIM, can provide the ability to control the tint level of EGUs based on a number of input triggers, including time of day, solar angle, daylight sensor values, commands, and I/O controller input, in some embodiments. The control intelligence's event programming can be custom configured for each installation. The control intelligence can include functionality for interfacing with building management systems, such as utilizing BACnet and LonWorks configurations, in some embodiments.
The on-site control infrastructure can also include one or more data collectors that can either be a part of the control intelligence modules, or be a separate module or component that communicates and/or connects to the control intelligence modules, in some embodiments. The data collectors can both actively ask questions, and passively listening for answers, in some embodiments. An on-site control infrastructure might include a plethora of broadcast data, in some embodiments. For example, the controllers and/or sensors of the on-site control infrastructure can broadcast data. This broadcast data might propagate throughout the on-site system, in some embodiments. A data collector can listen to and collect this broadcast data, in some embodiments. The data collector can also query other modules and components of the on-site control system, in some embodiments. The data collector can query a controller for data regarding a specific EGU, whether it is a pane or a sub-pane, for example. A sub-pane is an independently controllable pane of electrochromic glass that can be part of a larger pane. The term EGU can refer to either a pane or a sub-pane of electrochromic glass. The data collector can collect this data and provide it to a remote device monitoring and control system, in some embodiments.
The on-site control infrastructure can also aggregate data before it is sent to the remote device monitoring and control system, in some embodiments. This might be performed by the data collector, in some embodiments, or it might be performed by another module or component of the installation site control system. The on-site control infrastructure can aggregate packets of the on-site control infrastructure, in some embodiments. These might be Controller Area Network (“CAN”) bus packets, in some embodiments. For example, the data collector might aggregate one-hundred CAN bus packets. This aggregated data can be combined in one single message before it is provided to the remote device monitoring and control system. Different forms of this described process can be termed as a micro batching process. With micro-batching, many data points can be written into a single message, such as an IoT message, that is sent to the remote device monitoring and control system. Once the message arrives at the remote device monitoring and control system, it can then be expanded and parsed into the individual data points, in some embodiments. These data points can then be stored, analyzed and reported, in some embodiments.
When the installation site control system, which may include one or more data collectors, is installed at an installation site it generally has a decent connection to the Internet, and it is connected to many endpoint devices, such as EGUs, in some embodiments. These endpoint devices can be categorized as IoT devices, in some embodiments. Each of the windows or EGUs, or sub-panes of the EGUs, as well as the sensors, can be a device, in some embodiments. The installation site control system can be connected with all these devices, or at least has the ability to obtain information about all or most of these devices, such that it can communicate and/or receive telemetry data from and/or associated with the device. The installation site control system, including any data collectors, can receive information and/or telemetry data from a device, either directly or through another module such as a controller, or it can receive the information and/or telemetry data from the other module, such as the controller, regarding or associated with the device, such as an EGU.
The installation site control system can aggregate telemetry data from these devices. The installation site control system can aggregate information from various different devices, or multiple pieces of data, or data points, from some devices, along with a single piece of data from other devices. The installation site control system can aggregate these data points into a batch of data. The data points can be obtained from the devices, such as the EGUs for example. The data points can be received as separate packets that include one or more values for one or more metrics, as wall as possibly a timestamp, in some embodiments. The packets can be packed together into a single message that can be sent as a “micro-batch” to the device monitoring and control system.
This aggregation can be accomplished by one or more data collectors, in some embodiments. For example, the data collectors can aggregate around 100 data points from the various different devices of the installation site. These 100 data points can be from 100 different devices, or a smaller number of devices, where multiple devices can provide multiple data points. In some embodiments, the collection of the around 100 multiple data points to aggregate into a batch can take less than a second. The batched data can then be provided to device monitoring and control system, in some embodiments.
In some embodiments, each of the data packets are stored in a hexadecimal encoded format that can be expanded out further to get various metrics. Inside of the hexadecimal packet there can be a packet indicator, in some embodiments. The packet indicator can specify the type of the packet, or its length, for example. This hexadecimal indicator can be used for decoding individual packets, in some embodiments. In addition, a group of packets can be associated with one given timestamp, in some embodiments. The timestamp can be shared for the group of packets, such that the timestamp is only provided once for the group of packets, in some embodiments. The packets can be encoded using JSON, for example. The packets can be unpacked to determine shared characteristics. After the shared characteristics are determine, the packets can be repacked so that the shared characteristics are shared across multiple packets. For example, if multiple devices sent data to a data collector at the same time, instead of storing a timestamp in the JSON message, there can be one timestamp in the batched data that is associated with all the messages that arrived at that time. Therefore, the timestamp does not need to be replicated across the multiple different packets that arrived at the same time. Other types of common characteristics of the received packets can also be compressed in the batched data, depending on the embodiment.
The data collectors of the installation site control system can either passively and/or actively collect data, depending on the embodiment. The data collector can passively listen to data being sent or broadcast by various devices of the installation site. The data collector can actively send a request to a device or a controller for data regarding a specific device, such as an EGU, whether a pane or a sub-pane, in some embodiments. The data collector can de-prioritize itself if the system load is high, in some embodiments. The data collector can operate passively more that actively, so that the data collection does not interfere with normal operation of the equipment, in these embodiments.
There are many types of telemetry that can be collected from the different devices, depending on the embodiment. Some of the types of telemetry that are collected can be: target voltage of one or more EGUs, actual voltage of one or more EGUs, tint state of one or more EGUs, target current of one or more EGUs, actual current of one or more EGUs, target charge density of one or more EGUs, actual charge density of one or more EGUs, tint state for one or more EGUs, lux sensor readings, state information from the installation site control system, and/or state information of a controller of the electrochromic glass units, depending on the embodiment.
The architecture of the device monitoring and control system can comprise many different configurations, depending on the embodiment. The device monitoring and control system can be hosted by a provider network, in some embodiments. The device monitoring and control system in a provider network can be called an “IoT cloud” system in some embodiments. The device monitoring and control system can include a messaging hub/aggregator that can talk to multiple sites, in some embodiments. The messaging hub can perform two-way communication, in some embodiments. Users or clients can remotely access the systems of an installation site, such as an installation site control system, through the messaging hub of the device monitoring and control system, and using a gateway of an installation site.
The messaging hub can support two-way communication, from a remote application, such as a mobile app or ssh terminal for example, down to the site, and from the installation site to the device monitoring and control system, in some embodiments. From the installation site to the cloud, a message can be sent from the installation site, through the installation site gateway to the messaging hub of the device monitoring and control system, in some embodiments. From the messaging hub, the message can be stored in a data lake storage for raw data, in some embodiments. The data lake can preserve the raw data that the hub got, in some embodiments. The data lake can store the raw data in a cold storage, in some embodiments. This can allow future retrieval and analysis of the raw data, if a need to do so ever presented itself.
The device monitoring and control system can also include a data transformation module, in some embodiments. The data transformation module can receive data from the messaging hub, in some embodiments. The data transformation module might receive data from other modules or components, depending on the embodiment. The data transformation module can perform data expansion, as one of its types of functionality, in some embodiments. The data transformation module can receive a batched message that contains multiple data points batched within the message. The data transformation module can expand the message out into multiple pieces of data, in some embodiments. The data transformation module can also label items within the multiple data points, so that an individual data point is human readable, in some embodiments. The data transformation module can store the multiple expanded data points as multiple pieces of information in a data storage location, such as a database, in some embodiments. The database can store the transformed data for short-term storage, in some embodiments. This can be to allow users or application to look back over the data for a short-term time period, such as 30 days or 3 months, for example.
The device monitoring and control system can also include a streaming analytics pipeline, in some embodiments. The streaming analytics pipeline can receive data from the data transformation module, in some embodiments. The streaming analytics pipeline might receive data from other modules or components, depending on the embodiment. The streaming analytics pipeline can analyze the packets, such as the transformed multiple data points, in some embodiments. The streaming analytics pipeline can analyze the packets by performing one or more analytics functions on the received telemetry data, in some embodiments. These one or more analytics functions can include machine learning systems or algorithms to look for patterns in the telemetry data, in some embodiments. The streaming analytics pipeline can provide results of the analysis to a data analysis and reporting module. The data analysis and reporting module can be a type of data analytics interface, in some embodiments. The data analysis and reporting module can provide results of the one or more analytics functions to one or more remote destinations, in some embodiments. The data analysis and reporting module can report results to a remote destination, such as to a user, in a web application, in some embodiments.
The device monitoring and control system can also include a real-time monitoring web application module, either together with or separate from the data analysis and reporting module. The real-time monitoring web application module can also be a type of data analytics interface, in some embodiments. The real-time monitoring web application can obtain data from the streaming analytics pipeline and/or a database storage of the transformed data, depending on the embodiment. The real-time monitoring web application can broadcast alerts to a remote destination, such as to a user, in some embodiments. The real-time monitoring web application can output the state of various devices at one or more installation sites, in some embodiments. For example, the real-time monitoring web application can output the tint state of an EGU, whether it be a pane or a sub-pane, for example.
The device monitoring and control system can also include a control interface and/or a controller, in some embodiments. The control interface and/or controller can communicate with various internal or external clients, such as applications, modules and/or users, in some embodiments. The control interface and/or controller can obtain control instructions from these internal or external clients, to control one or more of the electrochromic glass units at respective ones of the installation sites. The sources can comprise a control application, such as a mobile app of a user, or an automated control system, such as an automated control system of the device monitoring and control system and/or provider network, depending on the embodiment. The control interface and/or controller can transmit control messages based on the control instructions to appropriate communication gateways for the appropriate installation sites, to implement the control instructions at the appropriate installation sites, such as at specific devices (like one or more EGUs) at the appropriate installation sites.
In some embodiments, a secure network connection can be established between a remote device monitoring and control system and an installation site control system, wherein updates are exchanged via the secure connection. In some embodiments, a third-party cloud provider may host the remote device monitoring and control system. In some embodiments, a system, such as at a customer-site, includes one or more computing devices configured to implement an installation site control system for an electrochromic glass system installed or to be installed at the customer-site. The installation site control system includes a gateway, configured to receive a pre-populated database for the electrochromic glass system from the remote device monitoring and control system, wherein the pre-populated database comprises respective mappings between respective controllers of the electrochromic glass system and respective electrochromic glass units of the electrochromic glass system. Also, the installation site control system and/or the remote device monitoring and control system can include a controller configuration module configured to identify respective ones a plurality of controllers of the electrochromic glass system and automatically configure, at the installation site, the respective ones of the installed controllers based on the respective characteristics of electrochromic glass units mapped to the respective controllers, where different ones of the electrochromic glass units have different characteristics. Furthermore, in some embodiments, the installation site control system comprises control intelligence, configured to coordinate control of the respective controllers mapped to the respective electrochromic glass units. In some embodiments, one or more control algorithms for the control intelligence are specified by the remote device monitoring and control system.
In some embodiments, a computer-readable medium stores program instructions, that when executed on one or more processors, cause one or more processors of the remote device monitoring and control system to discover controllers for electrochromic glass units connected to a network, and provide, to respective ones of the controllers, configuration parameters for particularly configuring the respective controllers to control respective electrochromic glass units to which the respective controllers are coupled, wherein the configuration parameters are provided based on respective mappings between controller identifiers for the respective controllers and characteristics of the electrochromic glass units to which the controllers are mapped, wherein the characteristics are stored in the remote device monitoring and control system.
An ongoing operational control phase can be performed to control the electrochromic glass units (e.g. EGUs or IGUs) using the remote device monitoring and control system communicating with the installation site control system installed at the customer-site. The remote device monitoring and control system may coordinate control of a plurality of local controllers, each associated with a respective electrochromic glass unit (e.g. EGU or IGU). Because different ones of the electrochromic glass units have different sizes and have other varying characteristics, the local controllers may need to be specifically configured to control a particular electrochromic glass unit coupled to the particular controller.
For example, in some embodiments, controllers of an electrochromic glass system may control respective electrochromic glass units to any one of eight or more tint levels. However, due to the different characteristics between the different electrochromic glass units, different voltages and current levels may need to be applied to the different electrochromic glass units to achieve similar tint levels. As an example, a first smaller EGU with a first set of characteristics may require X volts be applied to achieve a tint level 3, whereas another EGU with a different size and different characteristics may require Y volts be applied to achieve a tint level 3. Thus, the controller for the smaller EGU may need to be configured to output X volts for tint level 3, whereas the other controller may need to be configured to output Y volts for tint level 3.
In previous systems, controllers for particular EGUs have been configured for the particular EGUs at a time of manufacturing and prior to delivery of an electrochromic glass system to a customer-site. For example, the controller associated with the smaller EGU may have been configured at the factory to output X volts for tint level 3, whereas the other controller may have been configured at the factory to output Y volts for tint level 3. However, in such arrangements, if a controller is coupled to a different EGU than it was configured for at the time of manufacturing, the controller may not properly control the EGU to one or more specified tint levels. For example, if the controller for the smaller EGU ended up being coupled at the customer-site to the larger EGU, the controller may not properly control the larger EGU to tint level 3 by applying X volts (e.g. the voltage for the smaller EGU). Also, a piece of glass of a given EGU may break and be replaced with another EGU having different characteristics. In systems wherein controller configurations are performed at a time of manufacture and prior to installation, any changes such as switching controllers and EGU panels or replacing a broken EGU panel with a replacement EGU panel with different characteristics, may require the controller to be sent back to the factory to be re-configured or may require extensive re-wiring to relocate controllers from EGUs to which they are currently attached and to re-attach the controllers to EGUs to which they were intended to be attached based on original mappings used to configure the controllers.
The remote device monitoring and control system may communicate with an installation site control system to pre-populate a database of EGUs, controllers, sensors, etc. for a project. In some embodiments, the remote device monitoring and control system may implement a graphical user interface that enables a designer to graphically arrange EGUs, controllers, and sensors on one or more facades of a project (such as a wall of a building). In some embodiments, the remote device monitoring and control system may automatically generate mappings between controllers and EGUs. Also, the remote device monitoring and control system may automatically generate wiring diagrams, installation diagrams, installation procedures, etc. based on a current view of a project as reflected in a current project database. In some embodiments, the remote device monitoring and control system may automatically update a project database including determined mappings, parts lists, wiring diagrams, installation diagrams, installation procedures, etc. based on design changes provided to the remote device monitoring and control system. For example, a designer may change a size or location of an EGU and the remote device monitoring and control system may automatically update wiring diagrams, installation diagrams, installation procedures, etc. based on the updated design.
The remote device monitoring and control system may communicate with the installation site control system to provide the latest version of the project database along with wiring diagrams, installation diagrams, installation procedures, etc. The provided project database may be populated with EGU characteristic information, EGU layout information, controller layout information, sensor layout information, EGU to controller mappings, etc. The provided project database may be provided in a format compatible with the installation site control system, wherein the installation site control system adopts the populated project database as a local database to locally configure particular controllers based on characteristics of EGUs associated with the local controllers.
The local controllers installed at the customer-site may be coupled to a local network at the customer-site, such as an Ethernet network, and may advertise to, or be detected by, the installation site control system at the customer-site and/or the remote device monitoring and control system. Furthermore, the local controllers may advertise or otherwise communicate a controller ID associated with the respective local controllers to the remote device monitoring and control system and/or the installation site control system. The remote device monitoring and control system and/or the installation site control system may utilize mappings stored in the populated project database along with characteristics of the EGUs stored in the populated project database to determine how to particularly configure the respective local controllers. For example, the remote device monitoring and control system and/or the installation site control system may determine that a first local controller has a controller ID of 123 and may determine based on a mapping that controller 123 is mapped to a particular EGU. Furthermore, the remote device monitoring and control system and/or the installation site control system may store characteristic information for the particular EGU that may be used to determine voltage/current levels to be applied to the EGU to achieve particular tint levels. The remote device monitoring and control system and/or the installation site control system may further configure the controller 123 to output voltages based on the particular characteristics of the EGU to which the controller 123 is attached.
Because controllers are particularly configured, changes at the installation site may be automatically accounted for in the configuration of the controllers. For example, the remote device monitoring and control system may determine that controllers were switched when being coupled to a set of EGUs. In such a scenario, instead of having to remove the controllers and re-install the controllers on the originally intended EGUs, the remote device monitoring and control system may simply update the mappings. This may then cause the correct EGU characteristics to be associated with each of the controllers, such that the controllers are particularly configured using characteristics of the as-built EGUs.
Instead of being performed by the remote device monitoring and control system, the above procedures might instead be performed by the installation site control system, in some embodiments. Furthermore, an updated database may be exported from the installation site control system and imported or merged back into the remote device monitoring and control system. Additionally, importing the updated database from the customer-site may cause the remote device monitoring and control system to be automatically updated. Furthermore, EGU layout diagrams, EGUs to controller mappings, wiring diagrams, installation diagrams, installation procedures, etc. at the remote device monitoring and control system may be automatically updated to reflect the as-built configuration in the field, e.g. at the customer-site. This may be done without requiring a human technician to manually enter the as-built changes at the remote device monitoring and control system. In other embodiments, future upgrades or design changes may be designed on the remote device monitoring and control system, wherein a current version of the project database at the remote device monitoring and control system is updated as part of the upgrade or re-design. Additionally, an updated project database at the remote device monitoring and control system that includes changes as part of an upgrade project or re-design may further be exported back to the installation site control system when it is time to execute the upgrade project or re-design.
In some embodiments, in order to configure controllers at a customer-site or an installation site, the remote device monitoring and control system may execute a discovery process to discover controllers and/or other devices, such as sensors, connected to a local Ethernet network at the customer-site. In some embodiments, each device, such as a controller may be delivered to a customer- site with a pre-installed dynamic host configuration protocol (DHCP) module. The DHCP module may advertise a dynamic Internet Protocol (IP) address over the Ethernet network to the remote device monitoring and control system. The remote device monitoring and control system may then initiate or receive communications with the device (e.g. controller) using the dynamic IP address and determine a device ID of the device, such as a controller ID for a controller. The remote device monitoring and control system may further determine that the device ID (e.g. controller ID) is included in a pre-populated project database for the electrochromic glass system and may further assign a static IP address to the device (e.g. controller) and add the static IP address for the device (e.g. controller) to the project database for the electrochromic glass system. The remote device monitoring and control system may currently or subsequently perform a similar process for other devices, such as controllers, of the electrochromic glass system installed at the customer-site.
The remote device monitoring and control system can provide instructions to respective installation site control systems at one or more of the respective installation sites to change settings used to tint at least one of the respective EGUs at one or more of the installation sites. For example, the remote device monitoring and control system can receive telemetry data associated with the benchmarking of the state of the at least some of the EGUs installed at the respective installation sites. The remote device monitoring and control system can perform one or more analytics functions on some of the telemetry data associated with the benchmarking of the state of the EGUs at a data analytics engine. These one or more analytics functions can include machine learning systems or algorithms to look for patterns in the telemetry data, in some embodiments. Based on the results of the one or more analytics functions, the remote device monitoring and control system can provide instructions to the respective installation site control systems at one or more of the respective installation sites to change settings used to tint at least one of the respective EGUs at the respective installation sites. In addition, the results of these analytics can also be used to improve manufacturing of the EGUs by the EGU manufacturer. There are many different uses for the results of the analytics, and these examples should not be construed as being limiting.
In some embodiments, the remote device monitoring and control system may send configuration information to respective ones of the controllers identified during the discovery process to configure the respective controllers identified via the discovery process. The configuration information may be determined based on mappings between the respective controllers and EGUs, wherein the mappings can be determined by the remote device monitoring and control system. The configuration information can also be determined based on the telemetry data associated with the benchmarking of the state of the at least some of the EGUs installed at respective installation sites. Furthermore, the configuration information may be determined based on characteristics of the EGUs mapped to the respective controllers. Also, the mappings or EGU characteristics may be updated in the project database, for example via a graphical interface using the remote device monitoring and control system, and/or via importation of an updated version of the project database from the remote device monitoring and control system to the installation site control system, or vice-versa. The remote device monitoring and control system can therefore automatically re-configure the controllers for the EGUs as necessary based on updated mappings and/or characteristics of the EGUs.
In addition to controller to EGU mappings, in some embodiments a project database may include other mappings, such as: mappings for daylight and glare algorithms, zone mappings for zone-based control, scene creation mappings, wherein a set of EGUs are controlled in a coordinated fashion to create a scene, such as a company logo, etc. All of these mappings may depend on knowing where EGUs and associated controllers are positioned on a facade, such as a wall of a building. Also, in some embodiments a remote device monitoring and control system may automatically update these various types of mappings based on updates received either via a graphical interface, other user interface. For example, the remote device monitoring and control system may update such mappings in response to receiving as-built information about an electrochromic glass system, as an example.
A controller 160 of the device monitoring and control system 150 receives control instructions 162 from various sources (177, 178) to control one or more of the electrochromic glass units at respective ones of the installation sites (180, 190). The controller 160 can provide control messages to benchmark EGUs 164 based either on these received control instructions, and/or based on its own control intelligence, to the respective communication gateways (185, 195) of the installation sites (180, 190) through the communications hub 110, for the respective installation sites (180, 190) to implement the respective control instructions to benchmark EGUs at the respective installation sites, according to some embodiments.
In some embodiments, the device monitoring and control system 150, as well as any number of other possible services, operates as part of a service provider network 100 and each comprise one or more software modules executed by one or more electronic devices at one or more data centers and geographic locations. Client(s) and/or edge device owner(s) 172, 173, 174, 176, 177, and 178 using one or more electronic device(s) (which may be part of or separate from the service provider network 100) can interact with the various services of the service provider network 100 via one or more intermediate networks, such as the internet. In other examples, external clients or internal clients can interact with the various services programmatically and without user involvement.
A provider network 100 provides clients with the ability to utilize one or more of a variety of types of computing-related resources such as compute resources (for example, executing virtual machine (VM) instances and/or containers, executing batch jobs, executing code without provisioning servers), data/storage resources (for example, object storage, block-level storage, data archival storage, databases and database tables, etc.), network-related resources (for example, configuring virtual networks including groups of compute resources, content delivery networks (CDNs), Domain Name Service (DNS)), application resources (for example, databases, application build/deployment services), access policies or roles, identity policies or roles, machine images, routers and other data processing resources, etc. These and other computing resources may be provided as services, such as a hardware virtualization service that can execute compute instances, a storage service that can store data objects, etc. The clients (or “customers”) of provider networks 100 may utilize one or more user accounts that are associated with a client account, though these terms may be used somewhat interchangeably depending upon the context of use. Clients and/or edge device owners may interact with a provider network 100 across one or more intermediate networks (for example, the Internet) via one or more interface(s), such as through use of application programming interface (API) calls, via a console implemented as a website or application, etc. The interface(s) may be part of, or serve as a front-end to, a control plane of the provider network 100 that includes “backend” services supporting and enabling the services that may be more directly offered to clients.
To provide these and other computing resource services, provider networks 100 often rely upon virtualization techniques. For example, virtualization technologies may be used to provide clients the ability to control or utilize compute instances (e.g., a VM using a guest operating system (O/S) that operates using a hypervisor that may or may not further operate on top of an underlying host O/S, a container that may or may not operate in a VM, an instance that can execute on “bare metal” hardware without an underlying hypervisor), where one or multiple compute instances can be implemented using a single electronic device. Thus, a client may directly utilize a compute instance (e.g., provided by a hardware virtualization service) hosted by the provider network to perform a variety of computing tasks. Additionally, or alternatively, a client may indirectly utilize a compute instance by submitting code to be executed by the provider network (e.g., via an on-demand code execution service), which in turn utilizes a compute instance to execute the code—typically without the client having any control of or knowledge of the underlying compute instance(s) involved.
As indicated above, service provider networks have enabled developers and other users to more easily deploy, manage, and use a wide variety of computing resources, including databases. The use of a database service, for example, enables clients to offload many of the burdens of hardware provisioning, setup and configuration, replication, clustering scaling, and other tasks normally associated with database management. A database service further enables clients to scale up or scale down tables' throughput capacity with minimal downtime or performance degradation, and to monitor resource utilization and performance metrics, among other features. Clients can easily deploy databases for use in connection with a wide variety of applications such as, for example, online shopping carts, workflow engines, inventory tracking and fulfillment systems, and so forth.
The device monitoring and control system 150 can communicate with the installation site control system of an installation site (180, 190) to perform benchmarking of EGUs, in some embodiments. The benchmarking can include driving certain EGUs (182, 184, 186, 188, 189, 192, 194, 196, 198, 199) from clear to full tint, in some embodiments, or simply from one tint level to another, in other embodiments. Other types of EGU control, or simply analyzation of the telemetry of the EGUs without performing any specific control functions, can also be implemented to perform the benchmarking, depending on the embodiment. The benchmarking can also include driving the EGUs from full tint back to clear, or from the previous ending tint level back to the previous starting tint level, or simply from the previous ending tint level to another ending tint level, depending on the embodiment. The changing of the tint of the EGU can then be sampled, in some embodiments. The sampling can be at a very high rate, in some of these embodiments. The benchmarking might be performed only one window at a time, in certain embodiments, in order to not overload the installation site control system.
The benchmarking of an EGU can be performed on a regular, sporadic, and/or periodic basis, such as nightly or weekly, in some embodiments. For example, the same test might be performed on the EGU at regular, sporadic, and/or periodic basis. When performed regularly, sporadically, and/or periodically over a long-term period of time, the EGU can be analyzed, and the performance of the EGU can be determined over this period of time. For example, an analysis of the benchmarking data might determine that the performance of the EGU has degraded over time. In addition, analytics can be performed on the benchmarking data over time. The performance of the EGU can be compared to the outside temperature and/or humidity over multiple benchmarking points in time, for example.
The control messages regarding the benchmarking can specify, in some embodiments, that the benchmarking occur during low usage times of the EGUs at the respective installation sites. For example, the benchmarking activities (such as cycling an EGU from clear to full tint) can be set to occur during the night. As another example, the benchmarking activities can be set to occur on a weekend, if the installation site has low occupancy during the weekend, for example, resulting in low usage of the EGUs. In some embodiments, the device monitoring and control system 150 can with communicate with the installation site control system to specify some of the parameters of the benchmarking and then the installation site control system can perform the benchmarking itself. In other embodiments, the device monitoring and control system 150 can instruct the EGUs (either directly, or through the installation site control system as an intermediary, in some embodiments) to perform benchmarking activities (such as cycling the EGU from clear to full tint). In some of these embodiments, the device monitoring and control system 150 might instruct the EGU to perform the benchmarking activity, and then request data regarding that EGU from the installation site control system.
The device monitoring and control system 150 can also optimize the payload size and minimize the number of transactions from an installation site to a remote device monitoring and control system 150, in some embodiments. Some embodiments can utilize a micro-batching process where many data points are written into a single IoT message that is sent to the remote device monitoring and control system 150. Once the message arrives at the remote device monitoring and control system 150, it can then be expanded and parsed into the individual data points, in some embodiments. These data points can then be stored, analyzed and reported, in some embodiments.
The device monitoring and control system 150 can provide remote access and accessibility to an installation site control system, at an installation site, that controls the EGUs of the installation site, in some embodiments. The installation site control system can take inputs from sensors, such as lighting sensors, and input devices such as wall touch panels. The systems and methods for long-term benchmarking for electrochromic glass allows remote access to the system as well as for remote data logging, in some embodiments. Previously, an installation site control system was a closed system that existed on a network within the building, but remote clients/users did not have access to the system, and there was no real easy methods for communicating with the on-site control infrastructure at a building. The systems and methods for long-term benchmarking for electrochromic glass provides the mechanisms for communicating with the on-site controls infrastructure, which will then ultimately tint the EGUs, in some embodiments.
The device monitoring and control system 150 can allow for data collection of the installation site systems and components, as well, in some embodiments. The device monitoring and control system 150 can capture electronic characteristics regarding the properties, behavior, and functioning of the electrochromic glass at multiple installation sites, in some embodiments. An installation site control system can collect telemetry data from sources, such as EGUs, by using Internet of Things (“IoT”) techniques and functions, in some embodiments. The installation site control system can stream the data back to the remote monitoring and control system (which might be hosted by a provider network) for analysis and monitoring, in some embodiments. The remote monitoring and control system can send alerts, for example, if a particular EGU is behaving poorly. These alerts can be sent to a user, such as a building occupant, a customer, such as a building owner, or the EGU manufacturer, such as a remote field support monitoring system and/or service operations center, in some embodiments.
The device monitoring and control system 150 can analyze telemetry data received for EGUs at various installation sites. It can then provide instructions to respective installation site control systems at one or more of the respective installation sites to change settings for one or more respective EGUs at the one or more respective installation sites. For example, if the remote monitoring and control system detects that the response curve of an EGU is changing over time, it can then adapt the control algorithm for that particular EGU to compensate for the changing response curve. As another example, the remote monitoring and control system can determine that the response characteristics of an EGU changes with changes in temperature and/or humidity. It can then adapt the control algorithm for that particular EGU for different temperature and humidity characteristics to compensate for the changing response curve at the different temperature and/or humidity points.
The device monitoring and control system 150 can collect data from many different installation sites, either in a specific region or even around the world. The remote monitoring and control system can collect metadata of the EGUs at these many different installation sites, such as the direction one or more of the EGUs is facing, the time of day the data is taken for one or more EGUs, the temperature of the one or more EGUs, the size of the one or more EGUs, or the geolocation of one or more EGUs. The remote monitoring and control system can perform at a large scale, collect a vast amount of data, and analyze the vast amount of data using analytics. The remote monitoring and control system can search for patterns, either for individual EGUs or across installation sites. The remote monitoring and control system can search for patterns for similar products across multiple installation sites, for example. The remote monitoring and control system can search for patterns in data based on the collected metadata: such as the geolocation of the installation sites, the time of day the data is taken, the temperature of the EGUs, the size of the one or more EGUs, or the direction the EGU is facing at various installation sites. The results of these analytics can be used as feed back to tune the control algorithm of EGUs either at one installation site or many different installation sites. For example, the data from the analytics of an installation site can be used to fine-tune control algorithms for other installation sites. As a further example, these other installation sites might be located in the same city or region, or on the same or similar longitude, depending on the embodiment. In addition, the results of these analytics can also be used to improve manufacturing of the EGUs by the EGU manufacturer. There are many different uses for the results of the analytics, and these examples should not be construed as being limiting.
The device monitoring and control system 150 can allow the installation sites to operate as closed system, without any communication, monitoring, or control from a remote device monitoring and control system 150, in some embodiments. The installation site control system can operate independently from any external device monitoring and control system 150, in these embodiments. The installation site control system can receive data from sensors at the installation site, whether they be sensors for the EGUs, or sensors external to a building, or sensors internal to a building, and can perform operations to provide tinting of the EGUs based on its preprogrammed settings, for example. The installation site control system can perform local monitoring and control, in these embodiments. However, in preferred embodiments, the device monitoring and control system 150 can also allow the installation sites to operate as open systems, where they receive control from and provide data to a remote device monitoring and control system 150.
The device monitoring and control system 150 can also provide real-time or near real-time analysis and reporting of data. While the disclosed device monitoring and control system 150 can store data, such as in data lakes or databases, the data is not analyzed from the data storage systems, in some embodiments. Instead, the data in the device monitoring and control system 150 can be constantly in transit, such that it can provide real-time analysis and reporting, in these embodiments. The device monitoring and control system 150 can apply algorithms to streaming pipelines of data, where the data is data from an EGU installation site, in these embodiments. The data can be arriving to a data analysis engine as a stream, and the data analysis engine might look at a previous quantity of data to analyze and draw conclusions from, in some embodiments. For example, the data analysis engine might look at the last 15 minutes of data, and run its algorithms, analytics, and/or functions over the last 15 minutes of data constantly. The data analysis engine might also compare the streaming data, or a previous quantity of the streaming data, to previous data stored in data storage, in some embodiments.
The data analysis engine can, in some embodiments, compare telemetry data associated with the benchmarking of the state of the EGUs with previous stored telemetry data associated with the benchmarking of the state of the EGUs. When the data analysis engine acquires a signature from one of its algorithms, analytics, and/or functions it can provide an output to a destination, in some embodiments. This output can be, for example, an alert to a client, user and/or system administrator. For example, if the data analysis engine determines that the performance of an EGUs has degraded past a threshold, then it might provide an alert to a remote destination regarding the EGU, based at least in part on the determination, in some embodiments. The data analysis engine can also, in some embodiments, provide access to the stored telemetry data for a particular installation site to the one or more destinations associated with the particular installation site, while preventing the one or more destinations associated with the particular installation site from accessing stored telemetry data for other installation.
The architecture of the device monitoring and control system shown in
The messaging hub 210 can support two-way communication, from a remote application 270, such as a mobile app or ssh terminal for example, down to the site, and from the installation site to the device monitoring and control system, in some embodiments. From the installation site to the device monitoring and control system, a message can be sent from the installation site, such as a data collector (281, 291) at the installation site, through the installation site gateway (285, 295) to the messaging hub 210 of the device monitoring and control system, in some embodiments. From the messaging hub 210, the message can be stored in a data lake storage 215 for raw telemetry data associated with benchmarking of EGUs, in some embodiments. The data lake 215 can preserve the raw telemetry data associated with benchmarking of EGUs that the hub got, in some embodiments. The data lake 215 can store the raw telemetry data associated with benchmarking of EGUs in a cold storage, in some embodiments. This can allow future retrieval and analysis of the raw telemetry data associated with benchmarking of EGUs, if a need to do so ever presented itself.
The device monitoring and control system can also include a data transformation module 220, in some embodiments. The data transformation module 220 can receive raw telemetry data associated with benchmarking of EGUs from the messaging hub 210, in some embodiments. The data transformation 220 module might receive data from other modules or components, depending on the embodiment. The data transformation module 220 can perform data expansion, as one of its types of functionality, in some embodiments. The data transformation module 220 can receive a batched message that contains multiple data points batched within the message. The data transformation module 220 can expand the message out into multiple pieces of data associated with benchmarking of EGUs, in some embodiments. The data transformation module 220 can also label items within the multiple data points, so that an individual data point is human readable, in some embodiments. The data transformation module can store the multiple expanded data points as multiple pieces of information in a data storage location, such as a database 225, in some embodiments. The database 225 can store the transformed data associated with benchmarking of EGUs for short-term storage, in some embodiments. This can be to allow users or applications to look back over the data for a short-term time period, such as 30 days or 3 months, for example.
The device monitoring and control system can also include a streaming analytics pipeline 230, in some embodiments. The streaming analytics pipeline 230 can receive data associated with benchmarking of EGUs from the data transformation module 220, in some embodiments. The streaming analytics pipeline 230 might receive data from other modules or components, depending on the embodiment. The streaming analytics pipeline 230 can analyze the packets, such as the transformed multiple data points, in some embodiments. The streaming analytics pipeline 230 can analyze the packets by performing one or more analytics functions on the received telemetry data, in some embodiments. These one or more analytics functions can include machine learning systems or algorithms to look for patterns in the telemetry data, in some embodiments. The streaming analytics pipeline 230 can provide results of the analysis to a data analysis and reporting module 240. The data analysis and reporting module 240 can be a type of data analytics interface 140, in some embodiments. The data analysis and reporting module 240 can provide results of the one or more analytics functions to one or more remote destinations 270, in some embodiments. The data analysis and reporting module 240 can report results to a remote destination, such as to a user 270, in a web application, in some embodiments.
The device monitoring and control system can also include a real-time monitoring web application module 240, either together with or separate from the data analysis and reporting module. The real-time monitoring web application module 240 can also be a type of data analytics interface 140, in some embodiments. The real-time monitoring web application 240 can obtain data from the streaming analytics pipeline 230 and/or a database storage 225 of the transformed data, depending on the embodiment. The real-time monitoring web application 240 can broadcast alerts to a remote destination, such as to a user 270, in some embodiments. The real-time monitoring web application 240 can output the state of various devices at one or more installation sites, in some embodiments. For example, the real-time monitoring web application 240 can output the tint state of an EGU, whether it be a pane or a sub-pane, for example.
The device monitoring and control system can also include a controller 260, in some embodiments. The controller 260 can communicate with various internal or external clients, such as applications, modules and/or users 270, in some embodiments. The controller 260 can obtain control instructions from these internal or external clients 270, to control one or more of the electrochromic glass units at respective ones of the installation sites (180, 190). The sources can comprise a control application, such as a mobile app of a user, or an automated control system, such as an automated control system of the device monitoring and control system and/or provider network, depending on the embodiment. The controller 260 can transmit control messages based on the control instructions to appropriate communication gateways (285, 285) for the appropriate installation sites (180, 190), to implement the control instructions at the appropriate installation sites, such as at specific devices (like one or more EGUs) at the appropriate installation sites.
An on-site control infrastructure of
The on-site control infrastructure can also include one or more data collectors (381, 391) that can either be a part of the control intelligence modules (330, 340), or be a separate module or component that communicates and/or connects to the control intelligence modules (330, 340), in some embodiments. The data collectors (381, 391) can both actively ask questions, and passively listening for answers, in some embodiments. An on-site control infrastructure might include a plethora of broadcast data, in some embodiments. For example, the controllers (370a, 370b) and/or sensors (383, 393) of the on-site control infrastructure can broadcast data. This broadcast data might propagate throughout the on-site system, in some embodiments. A data collector (381, 391) can listen to and collect this broadcast data, in some embodiments. The data collector (381, 391) can also query other modules and components of the on-site control system, in some embodiments. The data collector (381, 391) can query a controller (370a, 370b) for data regarding a specific EGU (380a, 380b, 390a, 390b), whether it is a pane or a sub-pane, for example. A sub-pane is an independently controllable pane of electrochromic glass that can be part of a larger pane. The term EGU can refer to either a pane or a sub-pane, depending on the context. The data collector (381, 391) can collect this data and provide it to a remote device monitoring and control system in a provider network 300, in some embodiments.
The on-site control infrastructure can also aggregate data before it is sent to the remote device monitoring and control system, in some embodiments. This might be performed by the data collector (381, 391), in some embodiments, or it might be performed by another module or component of the installation site control system. The on-site control infrastructure can aggregate packets of the on-site control infrastructure, in some embodiments. These might be Controller Area Network (“CAN”) bus packets, in some embodiments. For example, the data collector (381, 391) might aggregate one-hundred CAN bus packets. This aggregated data can be combined in one single message before it is provided to the remote device monitoring and control system. Different forms of this described process can be termed as a micro-batching process. With micro-batching, many data points can be written into a single message, such as an IoT message, that is sent to the remote device monitoring and control system. Once the message arrives at the remote device monitoring and control system, it can then be expanded and parsed into the individual data points, in some embodiments. These data points can then be stored, analyzed and reported, in some embodiments.
When the installation site control system 310, which may include one or more data collectors (381, 391), is installed at an installation site it generally has a decent connection to the Internet, and it is connected to many endpoint devices, such as EGUs (380a, 380b, 390a, 390b), in some embodiments. These endpoint devices can be categorized as IoT devices, in some embodiments. Each of the windows or EGUs, or EGU sub-panes (380a, 380b, 390a, 390b), as well as the sensors (383, 393), can be a device, in some embodiments. The installation site control system 310 can be connected with all these devices, or at least has the ability to obtain information about all or most of these devices, such that it can communicate and/or receive telemetry data from and/or associated with the device. The installation site control system 310, including any data collectors (381, 391), can receive information and/or telemetry data from a device, either directly or through another module such as a controller (370a, 370b), or it can receive the information and/or telemetry data from the other module, such as the controller (370a, 370b), regarding or associated with the device, such as an EGU.
The installation site control system 310 can aggregate telemetry data from these devices. The installation site control system 310 can aggregate information from various different devices, or multiple pieces of data, or data points, from some devices, along with a single piece of data from other devices. The installation site control system 310 can aggregate these data points into a batch of data. The data points can be obtained from the devices, such as the EGUs (380a, 380b, 390a, 390b) for example. The data points can be received as separate packets that include one or more values for one or more metrics, as wall as possibly a timestamp, in some embodiments. The packets can be packed together into a single message that can be sent as a “micro-batch” to the device monitoring and control system.
This aggregation can be accomplished by one or more data collectors (381, 391), in some embodiments. For example, the data collectors (381, 391) can aggregate around 100 data points from the various different devices of the installation site. These 100 data points can be from 100 different devices, or a smaller number of devices, where multiple devices can provide multiple data points. In some embodiments, the collection of the around 100 multiple data points to aggregate into a batch can take less than a second. The batched data can then be provided to device monitoring and control system of a provider network 300, in some embodiments.
In some embodiments, each of the data packets are stored in a hexadecimal encoded format that can be expanded out further to get various metrics. Inside of the hexadecimal packet there can be a packet indicator, in some embodiments. The packet indicator can specify the type of the packet, or its length, for example. This hexadecimal indicator can be used for decoding individual packets, in some embodiments. In addition, a group of packets can be associated with one given timestamp, in some embodiments. The timestamp can be shared for the group of packets, such that the timestamp is only provided once for the group of packets, in some embodiments. The packets can be encoded using JSON, for example. The packets can be unpacked to determine shared characteristics. After the shared characteristics are determined, the packets can be repacked so that the shared characteristics are shared across multiple packets. For example, if multiple devices sent data to a data collector (381, 391) at the same time, instead of storing a timestamp in the JSON message, there can be one timestamp in the batched data that is associated with all the messages that arrived at that time. Therefore, the timestamp does not need to be replicated across the multiple different packets that arrived at the same time. Other types of common characteristics of the received packets can also be compressed in the batched data, depending on the embodiment.
The data collectors (381, 391) of the installation site control system 310 can either passively and/or actively collect data, depending on the embodiment. The data collector (381, 391) can passively listen to data being sent or broadcast by various devices of the installation site. The data collector (381, 391) can actively send a request to a device or a controller (370a, 370b) for data regarding a specific device, such as an EGU, whether a pane or a sub-pane, in some embodiments. The data collector (381, 391) can de-prioritize itself if the system load is high, in some embodiments. When de-prioritizing itself, the data collector (381, 391) can operate passively more that actively, so that the data collection does not interfere with normal operation of the equipment.
There are many types of telemetry that can be collected from the different devices, depending on the embodiment. Some of the types of telemetry that are collected can be: target voltage of one or more EGUs, actual voltage of one or more EGUs, tint state of one or more EGUs, target current of one or more EGUs, actual current of one or more EGUs, target charge density of one or more EGUs, actual charge density of one or more EGUs, tint state for one or more EGUs, lux sensor readings, state information from the installation site control system, and/or state information of a controller of the electrochromic glass units, depending on the embodiment.
The data collection chain functional group (F1) can include the installation sites control systems 505, including any data collectors that are part of the control systems at the installation sites. The installation site control systems 505 can communicate with the provider network 500 through an installation site gateway, in some embodiments. The installation sites communicate with an IoT Hub 510 of the provider network. They also communicate with a container registry 511 that stores configuration settings, and an IoT device provisioning service 590 that us part of the provisioning functional group (FX). The IoT hub 510 represents the communications hub between the systems operating in the provider network 500 and the installation sites 505. Raw data from the installation sites 505, such as messages that comprise batched telemetry data, can be stored in a data lake 512. The messages with the batched telemetry data can be provided to event driven functions 513. One of the functions of the event driven functions 513 can be to parse the batched data and/or expand the batched data into its component multiple individual data points. These multiple individual data points can be stored in a non-relational database 514. The data connectivity and transformation service 515 can structure the data in the non-relational database into tables appropriate for a relational database 532, and can provide the further structured data to the relational database 532.
The remote field support functional group (F2) can include an IoT device stream 520 that can be used by the remote field support operations 516, for example, to communicate directly with an installation site control system 505. Other users or clients, such as the service operations center 575, the remote field support monitoring 525, the data scientists 535, and/or the customers 555 might also communicate directly with an installation site control system 505 using a certain protocol, such as SSH for a secure shell. The device monitoring and control system can receive, via a controller, control instructions from these sources (such as the remote field support operations 516, the service operations center 575, the remote field support monitoring 525, the data scientists 535, and/or the customers 555) to control electrochromic glass units at an installation site, and can transmit control messages based on the control instructions to communication gateways for the respective installation sites to implement the respective control instructions at the respective installation sites.
The remote field support functional group (F2) also includes a web application 521 and/or a data visualization service 522 (which might also include some data analytics) that can be used by a remote field support monitoring user 525, to monitor installation sites, and potentially determine anomalies. The web application 531 and the data visualization service 522 can communicate with the relational database 532 which can operate as a structured data repository that stores the data to be analyzed and presented to the remote field support monitoring users 525.
The device monitoring and control system can obtain, through the IoT Hub 510 for example, connection protocol information for respective installation site control systems 505, where an installation site control system 505 communicates with the device monitoring and control system using one or more available connection protocols of a plurality of different connection protocols. This can occur through the actions of the event-driven functions 513, or the IoT device provisioning service 590, for example. The device monitoring and control system can register the connection protocol information for the installation site control systems. The connection protocol information can be registered in a container registry 511, for example. The device monitoring and control system might receive a connection interface query regarding a particular installation site control system 505. This can be received from the remote field support operations 516, the service operations center 575, the remote field support monitoring 525, the data scientists 535, and/or the customers 555. The device monitoring and control system can provide an indication of the one or more available connection protocols utilized by the particular installation site control system 505. The device monitoring and control system might receive a request from one of these entities to establish a connection with the particular installation site control system 505 using one of the available connection protocols. A connection for the requestor to the particular installation site control system 505 can be established through the IoT Hub, using the requested available connection protocol.
The data scientists' remote access functional group (F3) includes the relational database 532, which the data connectivity and transformation service 515 provides structured installation site telemetry data to. An analytics platform 530 can access the relational database 532 and perform one or more analytics functions on the structured telemetry data. These one or more analytics functions can include machine learning systems or algorithms to look for patterns in the telemetry data, in some embodiments. The results of the analysis from the analytics platform 530 can be sent to event-driven functions 513 that provide results of the one or more analytics functions to one or more remote destinations via a data analytics interface of the device monitoring and control system, such as the web apps (521, 573) or the web app node (550). Data scientists 535 can also analyze the results of the analytics platform 530, and can also use the analytics platform to perform custom or specific kinds of analytics on the structured data of the relational database 532.
The delivery and automation functional group (F4) includes the project development and management platform that can provide version control, reporting, requirements management, project management, automated builds, testing and release management capabilities for the remote monitoring and control system and/or various modules or components of the system, according to some embodiments. The project development and management control can also provide hosting for software development and version control, offer distributed version control and source code management functionality, and provide access control and collaboration features such as bug tracking, feature requests, task management, continuous integration and wikis for projects, according to some embodiments.
The mobile application and API functional group (F5) provides a web app node 550 for customers 555 using a mobile app 556, or a desktop interface, or a web browser interface, for example, to access telemetry data and/or results of analysis of telemetry data. It also provides a consumer identification service 552 to identify consumers and provide privacy and security of consumer information. It also includes an application programming interface (“API”) management 551 to interface between commands from these applications or clients, and the functionality of the device monitoring and control system. The mobile application and API functional group also provides the control applications, such as the mobile apps 555, the ability to control one or more of the electrochromic glass units at respective ones of the installation sites, by, for example, transmitting control messages based on received control instructions to communication gateways for installation sites to implement the control instructions at the installation sites.
The worldwide infrastructure extension functional group (F6) comprises the device twin service 560. The device twin 560 can comprise a plurality of control settings that are synchronized with a plurality of control settings of a particular installation site control system 505 of a particular installation site. In some embodiments, there can be a device twin 560 in the provider network, and a separate device twin at an installation site that is synchronized with device twin 560. The device twins might comprise status data that changes more slowly than telemetry data. The device monitoring and control system can receive a query from a client of the device monitoring and control system regarding one or more of a plurality of control settings of a particular installation site control system of a particular installation site, and can respond to the query from the client based at least in part on the control settings of the device twin, in some embodiments. Therefore, instead of a client, such as a user's mobile application, having to query the installation site for status data regarding the installation site, or devices of the installation site, the client can simply query the device twin 560, and the device twin 560 can respond to the client with the status data. The client can also modify certain status data of the device twin 560, such as for example the tint state of an EGU at an installation site, and the device twin 560 can synchronize with and/or update the device twin at the installation site, such that an action is performed at the installation site. Therefore, for example, if a client updates the tint state of an EGU in the device twin 560, then the device twin 560 can synchronize with the device twin at the installation site, which will then update the tint state of that EGU (whether a pane or a sub-pane) to the desired tint-state.
The premium monitoring functional group (F7) includes event-driven functions 571, that communicates with the non-relational database 514. The event-driven functions 571 can analyze the data of the non-relational database 514 as it is received to perform one or more analytics functions on the telemetry data. These one or more analytics functions can include machine learning systems or algorithms to look for patterns in the telemetry data, in some embodiments. The event-driven functions 571 can provide results of the one or more analytics functions to the asynchronous client notification service (572) which can communicate with a web app (573) to provide a mechanism for a service operations center (575) to interface with the results of the analysis. The asynchronous client notification service (572) can provide notifications of anomalies occurring at installation sites. The web app 573 can provide an interface for clients, such as the service operations center 575, to be notified of, and access the details, or any anomaly.
The provisioning functional group (FX) comprises the IoT device provisioning service 590. The IoT device provisioning service can, in some embodiments, enables the provisioning of millions of endpoint devices, such as IoT devices, which can include the EGUs and/or sensors of a multitude of installation sites in a secure and scalable manner. The IoT device provisioning service 590 allows many of the manual steps traditionally involved in provisioning to be automated in order to reduce the time to deploy IoT devices and lower the risk of manual error. The owner or manufacturer of the EGUs can add device registration information to an enrollment list, such as in the container registry 511, in some embodiments. The device, such as the EGU, sensor, or controller at the installation site can contact the device provisioning service 590. The device can pass identifying information to the device provisioning service to prove its identity. The device provisioning service 590 can validate the identity of the device by validating the registration ID and key against the enrollment list entry using, for example, either a nonce challenge (Trusted Platform Module) or standard X.509 verification (X.509), in some embodiments. The device provisioning service can register the device with the IoT hub 510. The device provisioning service 590 can also populate the device's desired twin state in the device twin service 560. The IoT hub 510 can return device ID information to device provisioning service 590. The device provisioning service 590 can return the IoT hub's 510 connection information to the device. The device can now start sending data directly to the IoT hub 510. The device can connect to IoT hub 510. The device can also get its desired state from its device twin in the device twin service 560.
The flowchart begins at 710 where an installation site control system of an installation site for electrochromic glass units (“EGUs”) receives control messages from a remote device monitoring and control system to benchmark the state of at least some of the EGUs installed at the installation site. Sometime after step 710, the flowchart then transitions to step 720 where during a during low usage times of the EGUs at the installation site, the installation site control system cycles the state of one or more EGUs between clear and full tint. The flowchart then transitions to step 730 in which the installation site control system of the installation site collects telemetry data associated with cycling the state of the EGUs between clear and full tint from various sources of data. The flowchart then determines, in step 740, whether the state of the EGUs has been cycled enough between clear and full tint to benchmark the state of the EGUs. If the EGUs have not been cycled enough the flowchart returns to step 720. If the EGUs have been cycled through enough times as determined in step 740, then the installation site control system adds the collected telemetry data to a batch in step 750, and then transmits a message comprising the batched data to a communications hub of a device monitoring and control system of a provider network remote from the installation site in step 760.
The flowchart begins at block 810 where a device monitoring and control system receives messages via a communication hub from communication gateways for remote installation sites of electrochromic glass units (“EGUs”), where the messages include batched telemetry data associated with the benchmarking of the state of the at least some of the EGUs installed at the respective installation sites, and where the batched telemetry data includes multiple individual data points. The flow chart then transitions to block 820 that expands the batched telemetry data into the multiple individual data points associated with the EGUs. After block 820, the flowchart stores the multiple individual data points in a data storage system, such that the telemetry data is aggregated over multiple installation sites for a period of time at block 830. In addition, after block 820, the flowchart provides the multiple individual data points to a data analytics engine at block 840. After block 840, the flowchart transitions to block 850, where the data analytics engine analyzes the multiple individual data points as they are expanded. The flowchart then determines whether an anomaly is detected in step 860. If an anomaly is detected then the flowchart transitions to block 870 which provides at least a near real time notification of the anomaly to one or more remote destinations. If an anomaly is not detected, the flowchart then transitions to block 880 which provides at least near real time results of the analysis to one or more destinations.
In at least some embodiments, a computer that implements a portion or all of a system for long term benchmarking for electrochromic glass as described herein may include a general-purpose computer system or computing device that includes or is configured to access one or more computer-accessible media, such as computer system 900 illustrated in
In various embodiments, computer system 900 may be a uniprocessor system including one processor 910, or a multiprocessor system including several processors 910 (e.g., two, four, eight, or another suitable number). Processors 910 may be any suitable processors capable of executing instructions. For example, in various embodiments, processors 910 may be general-purpose or embedded processors implementing any of a variety of instruction set architectures (ISAs), such as the x86, PowerPC, SPARC, or MIPS ISAs, or any other suitable ISA. In multiprocessor systems, each of processors 910 may commonly, but not necessarily, implement the same ISA.
System memory 920 may be configured to store instructions and data accessible by processor(s) 910. In various embodiments, system memory 920 may be implemented using any suitable memory technology, such as static random-access memory (SRAM), synchronous dynamic RAM (SDRAM), nonvolatile/Flash-type memory, or any other type of memory. In the illustrated embodiment, program instructions and data implementing one or more desired functions, such as those methods, techniques, and data described above for a system for long term benchmarking for electrochromic glass, such as a device monitoring and control system, are shown stored within system memory 920 as the code and data for a device monitoring and control system.
In one embodiment, I/O interface 930 may be configured to coordinate I/O traffic between processor 910, system memory 920, and any peripheral devices in the device, including network interface 940 or other peripheral interfaces. In some embodiments, I/O interface 930 may perform any necessary protocol, timing or other data transformations to convert data signals from one component (e.g., system memory 920) into a format suitable for use by another component (e.g., processor 910). In some embodiments, I/O interface 930 may include support for devices attached through various types of peripheral buses, such as a variant of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard, for example. In some embodiments, the function of I/O interface 930 may be split into two or more separate components, such as a north bridge and a south bridge, for example. Also, in some embodiments some or all of the functionality of I/O interface 930, such as an interface to system memory 920, may be incorporated directly into processor 910.
Network interface 940 may be configured to allow data to be exchanged between computer system 900 and other devices 960 attached to a network or networks 970, such as other computer systems or devices as illustrated in
In some embodiments, system memory 920 may be one embodiment of a computer-accessible medium configured to store program instructions and data as described above for
Any of various computer systems may be configured to implement processes associated with the provider network, a system and method for long term benchmarking for electrochromic glass, a device monitoring and control system, or any other component of the above figures. In various embodiments, the provider network, the system for long term benchmarking for electrochromic glass, or any other component of any of
Various embodiments may further include receiving, sending or storing instructions and/or data implemented in accordance with the foregoing description upon a computer-accessible medium. Generally speaking, a computer-accessible medium may include storage media or memory media such as magnetic or optical media, e.g., disk or DVD/CD-ROM, volatile or non-volatile media such as RAM (e.g. SDRAM, DDR, RDRAM, SRAM, etc.), ROM, etc, as well as transmission media or signals such as electrical, electromagnetic, or digital signals, conveyed via a communication medium such as network and/or a wireless link.
The various methods as illustrated in the Figures and described herein represent exemplary embodiments of methods. The methods may be implemented in software, hardware, or a combination thereof. The order of method may be changed, and various elements may be added, reordered, combined, omitted, modified, etc.
Various modifications and changes may be made as would be obvious to a person skilled in the art having the benefit of this disclosure. It is intended to embrace all such modifications and changes and, accordingly, the above description to be regarded in an illustrative rather than a restrictive sense.
This application claims benefit of priority to U.S. Provisional Application Ser. No. 63/250,085, entitled “SYSTEM AND METHOD FOR LONG-TERM BENCHMARKING FOR ELECTROCHROMIC GLASS,” filed Sep. 29, 2021, and which is hereby incorporated herein by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 63250085 | Sep 2021 | US |
