SYSTEM AND METHOD FOR OPTIMIZING HVAC SYSTEMS IN LARGE INSTITUTIONS USING WIRELESS PRESENCE DATA, SCHEDULING DATA, AND PREDICTIVE ANALYTICS

Description

CROSS-REFERENCE TO RELATED APPLICATION(S)

This application claims a benefit of priority under 35 U.S.C. § 119(e) from U.S. Provisional Application No. 63/695,061, filed Sep. 16, 2024, entitled “SYSTEM AND METHOD FOR OPTIMIZING HVAC SYSTEMS IN LARGE INSTITUTIONS USING WIRELESS PRESENCE DATA, SCHEDULING DATA, AND PREDICTIVE ANALYTICS,” which is fully incorporated by reference herein for all purposes.

TECHNICAL FIELD

This disclosure relates generally to building environmental control systems. In particular, this disclosure relates to systems and methods for determining and predicting building occupancy, which provides more accurate and real-time data for optimizing the energy usage of HVAC systems. Even more specifically, this disclosure relates to leveraging wireless presence data from existing infrastructure, integrating scheduling data, and using predictive analytics to provide improved control inputs for building management systems, including HVAC systems and geothermal loops.

BACKGROUND

The significant cost associated with heating and cooling large buildings poses a substantial challenge in facility management. A primary contributor to this expense is the necessity of regulating outside airflow, often mandated by health codes. These regulations frequently require facilities to introduce 100% outside air unless the actual occupancy of a space is precisely known, leading to considerable energy expenditure when cooling or heating this external air to desired internal temperatures.

The current industry standard for presence detection in educational institutions and large facilities primarily relies on CO2 sensors to approximate human occupancy within a given space. These sensors operate by measuring CO2 levels, with higher concentrations indicating the presence of people and lower levels suggesting a room may be unoccupied. For example, if CO2 levels rise above 1000 ppm, the system might trigger increased ventilation to introduce more outside air, thereby reducing CO2 concentrations. Conversely, levels around 300-400 ppm, which are similar to outdoor air, might indicate that a room is empty. While this method is widely used, it has several critical limitations that our innovative solution addresses.

CO2 sensors, while functional, present significant cost barriers, particularly for large institutions. The cost per sensor, including installation, often requiring dedicated wiring, is expensive, making widespread deployment financially prohibitive. Additionally, CO2 sensors require frequent recalibration, typically every 6-9 months. In practice, maintenance teams often cannot prioritize these recalibrations within their limited maintenance windows, leading to sensors becoming outdated and inaccurate. The practical lifespan of these sensors is typically only 2-3 years, and the financial burden of replacing or maintaining them across large campuses is rarely prioritized, resulting in uncalibrated systems that provide unreliable data.

Furthermore, CO2 sensors are generally specific to the particular building management system in use, meaning that a given company's sensors are typically supported only by their own systems. This leads to vendor lock-in, where institutions are constrained to using a specific set of sensors that may not be compatible with other systems. Such lock-in situations limit flexibility and can increase long-term costs as institutions are forced to continue using specific vendors' products.

In addition to these challenges, CO2 sensors have inherent disadvantages related to their operational effectiveness. They are reactive rather than proactive, meaning they can only respond to changes in occupancy after they occur. This delayed response is due to the time it takes for CO2 levels to build up or dissipate, which can result in HVAC systems being slow to adjust to the actual conditions in a room. This not only affects energy efficiency but can also lead to uncomfortable environments for occupants. Furthermore, CO2 sensors typically lack the granularity needed to determine precise occupancy counts, providing only a broad indication of presence rather than an accurate measure of the number of people in a space. This can lead to over-or under-conditioning of spaces, further reducing energy efficiency.

CO2 and other traditional occupancy sensors are also typically fixed in place and limited to the specific room or area where they are installed. This rigidity makes it difficult to adapt to changes in space usage, such as temporary reconfigurations or the introduction of new multipurpose spaces. Once installed, reconfiguring or relocating these sensors is costly and disruptive. Moreover, traditional occupancy sensors struggle to keep pace with modern work and learning environments, which are increasingly characterized by hybrid models where individuals frequently move between on-site and remote environments. These sensors are unable to account for these flexible usage patterns, leading to inefficient HVAC operations.

Therefore, there is a need for systems and methods for optimizing HVAC systems that overcome problems in the art.

SUMMARY

Methods are described that involve generating environmental control input data for a building management system (BMS) in a building. This process includes a computing system receiving wireless local area networking (WLAN) data from a plurality of wireless access points (APs) within a building, where this WLAN data is associated with various user devices present in different zones of the building. The computing system then processes the WLAN data to determine a real-time occupancy count for each of these zones. Using machine learning algorithms, the computing system forecasts a future occupancy count for each zone for an upcoming time period, basing these predictions on historical WLAN data, historical utilization data, and scheduled event data specific to each zone. Finally, the computing system generates environmental control set point data for the BMS, utilizing both the real-time occupancy count and the forecasted future occupancy count for each of the different zones.

In some embodiments, systems are described that generate environmental control input data for a building management system (BMS) in a building. Such a system comprises a processor and a non-transitory computer readable medium. This medium stores instructions that, when translated by the processor, cause a computing system to receive wireless local area networking (WLAN) data from a plurality of wireless access points (APs) within a building, the WLAN data associated with a plurality of user devices present in different zones of the building. The computing system processes this WLAN data to determine a real-time occupancy count for each of the different zones within the building. Furthermore, the computing system forecasts a future occupancy count for each of the different zones for a future time period using machine learning algorithms, where this forecasting is based on historical WLAN data, historical utilization data, and scheduled event data associated with each zone. Based on these real-time and forecasted future occupancy counts, the computing system generates environmental control set point data for the BMS.

In some embodiments, computer program products are described that comprise a non-transitory computer readable medium storing instructions. When these instructions are translated by a processor, they perform, within an enterprise computing network environment, the steps of generating environmental control input data for a building management system (BMS) in a building. This involves a computing system receiving wireless local area networking (WLAN) data from a plurality of wireless access points (APs) within a building, with the WLAN data being associated with user devices present in different building zones. The computing system processes this WLAN data to determine a real-time occupancy count for each of the different zones within the building. Subsequently, using machine learning algorithms, the computing system forecasts a future occupancy count for each of the different zones for a future time period, with this forecasting based on historical WLAN data, historical utilization data, and scheduled event data associated with each zone. Finally, the computing system generates environmental control set point data for the BMS based on the real-time occupancy count and the forecasted future occupancy count for each of the different zones.

These, and other, aspects of the disclosure will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following description, while indicating various embodiments of the disclosure and numerous specific details thereof, is given by way of illustration and not of limitation. Many substitutions, modifications, additions and/or rearrangements may be made within the scope of the disclosure without departing from the spirit thereof, and the disclosure includes all such substitutions, modifications, additions and/or rearrangements.

BRIEF DESCRIPTION OF THE FIGURES

The drawings accompanying and forming part of this specification are included to depict certain aspects of the invention. A clearer impression of the invention, and of the components and operation of systems provided with the invention, will become more readily apparent by referring to the exemplary, and therefore nonlimiting, embodiments illustrated in the drawings, wherein identical reference numerals designate the same components. Note that the features illustrated in the drawings are not necessarily drawn to scale.

FIG. 1 is an example architecture diagram illustrating the system's components and their interactions.

FIG. 2 is a sequence diagram illustrating the operation of the invention.

FIG. 3 is a flowchart illustrating a method for generating environmental control input data for a building management system.

FIG. 4 depicts a diagrammatic representation of a data processing system for implementing systems and methods for determining and predicting building occupancy.

DETAILED DESCRIPTION

The invention and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known starting materials, processing techniques, components and equipment are omitted so as not to unnecessarily obscure the invention in detail. It should be understood, however, that the detailed description and the specific examples, while indicating some embodiments of the invention, are given by way of illustration only and not by way of limitation. Various substitutions, modifications, additions and/or rearrangements within the spirit and/or scope of the underlying inventive concept will become apparent to those skilled in the art from this disclosure.

Generally, the present disclosure describes a system and method that leverages the ubiquitous presence of Wi-Fi infrastructure, which is typically already an integral part of modern educational institutions. Wi-Fi is essential to the operation of these institutions and is supported by existing IT infrastructure, making it a cost-effective and reliable option for presence detection. Unlike CO2 sensors, Wi-Fi-based systems do not require additional hardware installations, complex wiring, or frequent maintenance. They utilize the existing network to track device presence, offering real-time data on occupancy without the recurring costs and logistical challenges associated with traditional sensors. This approach provides a seamless and scalable solution for monitoring space utilization across large campuses. Commonly-owned U.S. Pat. No. 10,909,867, entitled “SYSTEM AND METHOD FOR OPTIMIZING HVAC SYSTEMS IN LARGE INSTITUTIONS USING WIRELESS PRESENCE DATA, SCHEDULING DATA, AND PREDICTIVE ANALYTICS,” describes a system that passively collects wireless data from school access points to objectively measure and track student behaviors on campus with respect to time and place, and is fully incorporated by reference herein for all purposes.

The real-time data provided by the disclosed Wi-Fi-based system offers significant advantages over CO2 sensors. While CO2 sensors provide lagging indicators of occupancy, our system delivers immediate insights, allowing HVAC systems to respond quickly to changes in occupancy. This ensures that spaces are conditioned appropriately as soon as they are occupied, enhancing both energy efficiency and occupant comfort. Additionally, as described in detail below, the disclosed system's predictive capabilities allow it to anticipate changes in occupancy based on historical patterns, further improving operational efficiency.

The disclosed system is also inherently scalable because it leverages the existing Wi-Fi infrastructure, which is already deployed campus-wide. This makes it easy to scale the system across large institutions without the need for additional hardware. Furthermore, the system's flexibility allows it to adapt to changing space configurations or usage patterns without requiring costly modifications. By eliminating the need for dedicated sensors, wiring, and frequent maintenance, the disclosed Wi-Fi-based system offers a significantly lower total cost of ownership compared to traditional CO2-based systems.

One challenge in managing building environments is the lack of integration between booking systems and HVAC controls. Currently, no automated systems exist to synchronize event schedules with HVAC operations. This leads to inefficiencies where HVAC systems are not optimized based on actual room usage, resulting in wasted energy and suboptimal environmental conditions. The absence of a seamless integration mechanism means that HVAC systems often run at full capacity for rooms that may not be in use, or fail to adjust adequately for rooms that become unexpectedly occupied, exacerbating inefficiencies.

A further complication arises from the disparate naming conventions across various systems. Over time, building names, room identifiers, and other critical data points can change due to renovations, rebranding, or administrative decisions. However, these changes are often not uniformly updated across all systems, leading to a disconnect between the calendar system, the building management system, and the Wi-Fi system. This disjointed data management becomes particularly problematic in large institutions managing over 2 million square feet of space, where the cumulative effect of these inconsistencies can lead to significant inefficiencies and errors.

One differentiator of the disclosed system is its ability to intelligently manage and resolve name changes across decentralized systems. The disclosed solution maintains a comprehensive record that links old and new names, ensuring continuity and accuracy across all platforms, even as building or room identifiers change. This capability is critical in large, dynamic environments where system entropy can lead to data fragmentation over time. Furthermore, the ubiquitous nature of Wi-Fi means that the system can be deployed across any part of the campus without additional infrastructure investments, offering a scalable, cost-effective solution that outperforms traditional presence detection methods in both reliability and ease of use.

The disclosed system's ability to integrate data from various sources, including scheduling systems, Wi-Fi data, and potentially even existing sensors, provides a more comprehensive view of space utilization. This holistic approach allows for more informed decision-making regarding HVAC operations, space planning, and overall campus management. Additionally, the system is designed with the end-user in mind, providing easy access to data through intuitive dashboards and reports. This user-centric design ensures that facilities managers and campus administrators can quickly understand and act on the information provided, enhancing the overall effectiveness of campus operations.

The disclosed innovative approach to presence detection and HVAC integration represents a significant enhancement over existing industry standards. By leveraging existing Wi-Fi infrastructure, the system eliminates the need for costly and maintenance-intensive CO2 sensors, providing a more reliable and scalable solution. The disclosed system also addresses the critical issue of integrating scheduling data with HVAC controls, ensuring that energy usage is optimized based on actual room occupancy. By utilizing the BACnet protocol, the solution avoids vendor lock-in, offering compatibility with a wide range of building management systems. BACnet, or Building Automation and Control Network, is a communication protocol designed to enable different building automation devices from various manufacturers to speak the same language. BACnet is a global standard developed by the American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE) and is used in a wide range of building systems. Combined with an intelligent name resolution capability and future-proof design, this makes the disclosed solution an advanced and practical choice for large educational institutions and other expansive facilities.

This disclosure outlines an advanced real-time presence detection and data processing system designed to optimize space utilization and energy management in large-scale facilities, such as educational institutions. This system integrates on-premises data collection, cloud-based processing, and secure data transmission to provide comprehensive and actionable insights. By leveraging existing wireless network infrastructure, modular Dockerized containers, and robust cloud services, the system offers significant advancements over traditional presence detection technologies.

In some embodiments, the system operates by collecting data from network devices through syslog messages and SNMP (Simple Network Management Protocol) traps, which are then securely transmitted to AWS Kinesis for further processing. AWS Lambda functions play a role in normalizing and processing this data, ensuring that it is correctly stored and ready for analysis. The system is designed to handle large volumes of data in real-time while maintaining high standards of security and privacy.

In some embodiments, the system employs on-premises data collection and processing as a fundamental step in its operation. Network devices, such as wireless access points (APs), routers, and switches, are configured to forward syslog messages and SNMP traps to an on-premises virtual machine (VM) to capture all relevant network events for processing.

While other embodiments may be used, following is one example of on-premises data collection and processing implementation. For Cisco Meraki, administrators configure syslog forwarding in the Meraki dashboard, directing logs related to wireless association and disassociation to the VM's IP address. For Aruba Networks, administrators use the ArubaOS CLI to issue commands that direct logs and SNMP traps to the on-prem VM. Mist Systems are configured to send event data, including user location updates and device associations, to the VM via webhooks in real-time.

The on-premises VM operates within a Dockerized container environment, with each container handling specific data tasks. The VM is configured to listen for incoming syslog messages and SNMP traps on a UDP socket bound to port 514 (for example), which has a 1 MB buffer to manage high traffic volumes. Syslog messages are filtered using keywords relevant to presence detection, such as “assoc,” “auth,” and “roam,” while SNMP traps are translated from raw OID values into human-readable formats using predefined MIBs. After this processing, data packets are securely transmitted to an AWS Kinesis stream via HTTPS, with each packet containing event data, a timestamp (rec_ts), and metadata like school ID and building ID. Finally, the VM incorporates a logging mechanism that records the number of discarded packets every 60 seconds, providing insight into the efficiency of the filtering process.

Once the processed data packets are securely transmitted from the on-premises VM to an AWS Kinesis stream via HTTPS, the system proceeds with cloud-based data processing utilizing a series of AWS Lambda functions. These Lambda functions are specifically designed to efficiently handle data normalization, manage errors, and ensure the final storage of data in appropriate databases, operating at scale to process high volumes of information with minimal latency.

AWS Kinesis serves as the primary entry point for all data originating from the on-premises VM, configured to ingest data at high speeds, thereby ensuring that even large bursts of syslog or SNMP messages are managed without delay. Each data packet transmitted to Kinesis is structured to include fields such as institution ID, event type, timestamp, and location data, a design that facilitates consistent processing by subsequent Lambda functions.

A dedicated Lambda function primarily handles data normalization, ensuring consistency across various data sources and preparing the data for effective storage and analysis. This normalization process involves retrieving and decoding base64-encoded data from Kinesis, then parsing it using specialized parsers tailored for different data sources such as MerakiWifi, MistSession, Syslog, and SNMP, which ensures accurate interpretation and normalization of diverse data formats. Furthermore, this function addresses potential data inconsistencies, for instance, by normalizing incorrectly formatted timestamps into a consistent format. To maintain data integrity and prevent duplicate processing of events, such as multiple association events from the same device, the Lambda function implements a debounce mechanism using Redis, which checks for similar previously processed events within a specified time window and discards duplicates. Additionally, the function performs Access Point (AP) and identity lookups to enrich the event data with contextual information, matching it with specific AP details like location and capacity, and correlating device information with user identity for accurate tracking.

Following normalization, another Lambda function manages the storage of this data in various AWS services, making it available for both real-time access and historical analysis. For real-time applications, critical data like active sessions and occupancy levels are stored in Redis, allowing for quick access by real-time dashboards or other applications, with built-in logic for data expiration and cache management to optimize performance and resource utilization. For long-term archiving, the Lambda function writes both raw and normalized data to AWS S3, leveraging its scalable storage capacity. Time-series data, specifically historical occupancy trends, is formatted and stored in AWS Timestream, where it can be queried for analyzing trends over specific periods.

The system also incorporates a robust error handling and notification system within the Lambda functions to promptly address any issues encountered during data processing. If an error occurs while processing a record, the function logs the error and dispatches a notification through a dedicated service, ensuring system administrators are immediately alerted for corrective action. In scenarios where the Lambda function fails to upload records to Kinesis or another service, a retry mechanism is triggered; if retries continue to fail, the function logs the failed records and raises a FailedUploadError, aiming to minimize data loss and document failures for subsequent review.

Following the comprehensive cloud-based data processing, the AWS Lambda functions also play a vital role in managing device rankings, which is beneficial for accurate presence detection and user tracking. A separate Lambda function is specifically implemented for the device ranking algorithm, which periodically evaluates and ranks devices based on predefined criteria. These criteria include factors such as connection time, the number of access points (APs) a device is connected to, and the device type. The Lambda function continuously updates these rankings using the latest available data, thereby ensuring that the primary device for each unique user is accurately identified. The results generated by this device ranking algorithm are then stored in Redis, which allows other Lambda functions to quickly access these rankings during subsequent data processing steps. This integration with Redis ensures that the system always has the most current device rankings readily available for efficient lookup, enabling the system to effectively determine the primary device associated with any user during its data processing operations.

Following the process of device ranking and primary device identification, the system also integrates robust privacy mechanisms, with AWS Lambda functions playing an integral role in maintaining user privacy. These privacy measures are fundamental to the system's design.

To ensure user anonymity, the Lambda functions mask user identifiers by applying a one-way cryptographic hashing algorithm before any data is stored or processed. This hashing algorithm is designed to be robust, making it impossible to reverse-engineer the original user identities, which is essential for preserving user anonymity while still allowing for effective tracking and analysis of data. Beyond masking, the Lambda functions further implement additional anonymization techniques to remove personally identifiable information (PII) from the collected data. This anonymization process involves stripping out any metadata that could potentially identify a user indirectly and ensuring that all data processing complies with stringent privacy regulations such as FERPA and GDPR, thereby protecting user privacy while enabling the system to generate valuable insights.

With the data successfully collected, processed, ranked, and anonymized, the system then proceeds to organize this event data within a robust database, such as AWS Timestream, tying each event to a specific timestamp, location, and user/device information. This comprehensive dataset, which also includes detailed information about each zone—such as its capacity, building, floor level, usage types, and square footage—enables the calculation of occupancy, utilization rates, and deeper insights into space usage.

This organized data allows the system to periodically calculate occupancy counts in various zones at specific time intervals. This process involves running periodic queries to aggregate the number of unique users in each zone, comparing this count to the zone's defined capacity, and subsequently storing these results along with other pertinent zone-related information. The system maintains a detailed zone table that stores attributes for each facility zone, including its maximum capacity, associated building name, floor level, primary and secondary usage types, square footage, and hours of operation in a JSON format (or in other structures, as one skilled in the art would understand). This allows the system to factor operational hours into utilization rate calculations.

To ensure up-to-date records of occupancy and capacity utilization, the system executes queries at regular intervals, for example, every 10 minutes. These queries aggregate event data to create a snapshot of unique user counts within each zone, then calculate the capacity percentage by comparing the unique user count to the zone's maximum capacity. For instance, a query calculates the number of unique users in each zone over the last 10 minutes, determines the capacity percentage, and stores this information, including building name and floor level. The results of these periodic queries are then stored in the database at 10-minute intervals in an zone_occupancy table, which provides a granular view of how unique user counts and capacity percentages evolve over time, complete with detailed zone information.

In addition to meticulously tracking real-time occupancy and capacity percentages, the system further proceeds to calculate and store the overall utilization rate for each zone. This utilization rate is a more comprehensive metric, designed to holistically factor in both the occupancy over time and the designated hours of operation for each specific zone. This metric is derived by comparing the actual usage of a space, which refers to the periods during which the zone is occupied, against its potential usage, defined by the total available hours of operation.

In some embodiments, the system calculates this utilization rate using a formula that aggregates occupancy counts across specified intervals, multiplies them by the duration of these intervals, and then divides this sum by the product of the zone's maximum capacity and its total operational minutes. The total_operational_minutes value is dynamically derived from the hours_of_operation data, which is stored in a JSON format within the zone table. This detailed calculation allows the system to accurately assess how effectively a space is being utilized. The calculated utilization rates are subsequently stored in a separate zone_utilization table. This table tracks the utilization rate at specified intervals, thereby enabling long-term analysis to understand and optimize how effectively different zones within the facility are being used over time.

With the unique user counts, capacity percentages, and utilization rates now meticulously calculated and stored at regular intervals, the system has amassed a comprehensive dataset that captures these critical metrics across various time periods. This rich dataset is invaluable for facility managers, as it can be queried and analyzed to understand overarching trends in space utilization, pinpoint peak usage times, and ultimately optimize facility management practices.

This aggregated data allows the system to effectively track the number of unique users within specific zones over time, providing insights into how these numbers compare against the maximum capacity of each space. Furthermore, it details how efficiently each space is being utilized, taking into account its designated hours of operation. For instance, facility managers can retrieve historical data for a specific zone to analyze past trends and inform data-driven decisions. Similarly, the system can calculate the average utilization rate across all zones within an entire building over a defined time period, such as a month, which helps in identifying how effectively different parts of a building are being used. At this stage, the system has successfully completed the calculation and storage of zone counts, capacity percentages based on unique users, and their corresponding utilization rates, typically updated at 10-minute intervals. The integration of detailed zone information, including building, floor level, usage types, and capacity, along with the consideration of operational hours, provides a thorough and continuous analysis of space utilization, empowering facility managers to optimize resource allocation, enhance space management, and ensure efficient zone usage throughout the facility.

Building upon this robust foundation of real-time and historical occupancy data, the system then progresses to implement a sophisticated forecasting model designed to predict the number of people expected to be present in a room over the next 24 hours, with predictions delivered at hourly intervals. This proactive forecasting capability is beneficial for advanced facility management, enabling adjustments to be made to HVAC settings, staffing levels, and other resources well in advance, based on anticipated occupancy rather than reactive measures.

Building upon this robust foundation of real-time and historical occupancy data, the system then progresses to implement a sophisticated forecasting model designed to predict the number of people expected to be present in a room over the next 24 hours, with predictions delivered at hourly intervals. This proactive forecasting capability is beneficial for advanced facility management, enabling adjustments to be made to HVAC settings, staffing levels, and other resources well in advance, based on anticipated occupancy rather than reactive measures.

The forecasting approach leverages historical occupancy data stored within the system to predict future occupancy levels. For this purpose, the system utilizes tools such as Amazon Forecast, which supports models like ARIMA (AutoRegressive Integrated Moving Average), to generate these hourly forecasts for the subsequent 24-hour period. While the overall methodology is explained, the system may also apply different weights and additional tuning to further refine and improve the accuracy of these forecasts.

Before the forecasting model can be run, it is essential to prepare the necessary data. This data preparation process involves extracting historical occupancy data at hourly intervals, along with other relevant features that could influence occupancy patterns. Specifically, the system extracts this historical occupancy information from the zone_occupancy table, which already contains records of unique user counts at specified intervals. For example, a query is used to retrieve data for the past 30 days to train the forecasting model. To enhance the model's accuracy, additional features such as the day of the week, holiday indicators, and specific events can be included in this data. Furthermore, if data from more than a year ago is available, the system will incorporate data from the same month of the previous year. Once extracted, this data is then formatted into a time-series dataset, making it suitable for input into Amazon Forecast. This dataset includes the timestamp, the unique user count (which serves as the target variable for prediction), and any other pertinent features.

To further improve the accuracy of the forecasting, the model can incorporate a selection of specific features that are known to influence occupancy patterns. These features include the day of the week, as different days often exhibit distinct occupancy trends; holiday indicators, given that occupancy is typically lower on holidays; previous year occupancy, recognizing that patterns can repeat annually; previous hourly occupancy, as recent past occupancy levels are strong predictors of immediate future levels; and events or special occurrences that might significantly impact expected attendance.

Following the preparation of data, the system proceeds with the implementation of the forecasting model, which encompasses setting up Amazon Forecast, training the model using historical data, and subsequently generating predictions for the next 24 hours. While Amazon Forecast is utilized, it is noted as one of many tools that can achieve this forecasting objective.

To set up Amazon Forecast, the first step involves creating a dataset group within the Amazon Forecast console, which will serve as the repository for the time-series occupancy data. Next, the system imports the prepared dataset by defining its schema, including fields for timestamp, zone_id, unique_user_count, day_of_week, and is_holiday, and then importing this formatted dataset from an S3 bucket into Amazon Forecast. For the actual forecasting, the ARIMA (AutoRegressive Integrated Moving Average) model is selected as the forecasting recipe within Amazon Forecast, which automatically manages hyperparameter optimization and model validation. The system then trains this ARIMA model using the imported dataset, a process that involves dividing the data into training and validation sets, optimizing the model's parameters, and evaluating its performance.

Once the model is thoroughly trained, the system moves on to generating the 24-hour forecast. This involves creating a forecast using the trained ARIMA model, specifying a forecast horizon of 24 hours and a prediction granularity of hourly intervals. This request also generates multiple quantiles (e.g., 10th, 50th, and 90th percentiles) to capture various levels of uncertainty within the predictions. Finally, the generated forecast data is stored and utilized either in an S3 bucket or directly ingested back into the Timestream database, enabling further analysis and integration with building management systems. This storage includes the predicted occupancy data for each zone at each hourly interval, along with its associated prediction quantile.

The system's advanced predictive capabilities extend to identifying and forecasting occupancy patterns in spaces that, while not formally scheduled in a booking system, exhibit consistent, recurring usage patterns. Within large institutions, many areas may not have official schedules but are regularly used by groups or individuals at predictable times. For instance, the system can predict that a specific classroom, even if it appears unscheduled, will have approximately 15 people present every Friday at 3:00 PM, based on observed historical Wi-Fi data collected over several weeks.

To achieve this, the system can continuously analyze historical Wi-Fi usage patterns for all spaces, including those without formal bookings, to discover and learn these organic routines. By recognizing such established, repeated behaviors, the system gains the ability to proactively predict future occupancy levels for these otherwise unscheduled periods. This predictive insight is beneficial as it enables the system to optimize building environmental controls, such as adjusting HVAC settings, for these spaces in advance. This capability ensures that resources are allocated based on anticipated, actual usage, leading to significant energy savings by preventing unnecessary conditioning of spaces or by preparing them for expected, informal gatherings. This unique aspect complements the system's ability to refine forecasts for formally scheduled events by also addressing the dynamic occupancy needs arising from informal, yet predictable, space utilization.

Beyond leveraging historical occupancy data, the system significantly enhances its occupancy forecasting capabilities by integrating scheduling data through an API. This integration allows the system to ingest detailed schedules for each room, encompassing classes, events, clubs, meetings, and other activities. By combining this scheduling information with actual occupancy data gathered from similar past events, the system refines its forecasts, thereby providing more accurate predictions specifically for rooms with scheduled events.

Building on the enhanced occupancy forecasting capabilities, the system further refines its predictions by integrating scheduling data through an API. This beneficial integration enables the system to ingest detailed schedules for each room or zone within a facility, capturing vital information such as the timing, type, and expected attendance for various classes, events, clubs, meetings, and other activities. By combining this comprehensive scheduling information with actual occupancy data from similar past events, the system is able to provide more accurate occupancy forecasts specifically for rooms with scheduled events.

To achieve this, the system employs an API to regularly pull scheduling data from integrated platforms. This ingested data extends beyond just the event timing to include metadata such as the event type, expected attendance, and any special requirements. For instance, an API request can retrieve schedules for all rooms between specified dates, returning a list of scheduled events. This detailed scheduling data is then structured and stored in a dedicated room_schedules table within the database. This table tracks critical event details including an event_id, zone_id, event_name, event_type, start_time, end_time, expected_attendance, and other metadata in JSON format. This comprehensive storage of scheduling information for each zone is foundational for the system's ability to enhance its predictive model.

Following the ingestion of detailed scheduling data, the system proceeds to a beneficial step: measuring actual occupancy during these scheduled events to compare it against the expected attendance. This direct comparison is fundamental for truly understanding how various event types influence room occupancy and is essential for continually refining and improving the system's forecasting model.

Specifically, during the runtime of each scheduled event, the system diligently tracks the actual number of unique users present within the designated room or zone. This real-time occupancy data is recorded and stored in direct relation to the specific event taking place. For instance, a query is executed to insert data into an event_occupancy table, which selects the event_id and zone_id from the room_schedules table, along with a timestamp, and then counts the distinct user_ids from the event_data table. This process involves joining the event_data with access_points and room_schedules to ensure that only unique users within the correct zone and during the event's start_time and end_time are counted and grouped by event and zone. This detailed tracking allows the system to accurately capture the actual attendance, which can then be directly compared with the expected attendance to reveal attendance patterns.

The actual occupancy data gathered for each event is then stored in a dedicated event_occupancy table within the database, facilitating detailed analysis and direct comparison with the initially expected attendance. This table's structure includes the event_id, zone_id, timestamp, and unique_user_count, with a primary key composed of the event_id and timestamp. This robust storage mechanism enables the system to comprehensively analyze how well-attended various events were in contrast to their scheduled expectations, thereby providing invaluable insights into attendance patterns for different types of events. This refined understanding is critical for continually enhancing the accuracy of future occupancy forecasts.

Building upon the detailed analysis of actual occupancy during scheduled events, the system then proceeds to enhance its forecasting accuracy by integrating this event-specific data into its predictive model. This approach allows the system to generate more precise predictions for upcoming scheduled events by combining insights from past similar events with generalized forecasting data.

When the system needs to forecast occupancy for a room with an upcoming scheduled event, its initial step involves querying historical event data to identify past events that share similarities in type, time, and expected attendance. This historical information is beneficial for establishing a baseline for the current forecast. For instance, a query can be executed to retrieve the average attendance from these similar past events, providing a robust empirical foundation for the prediction. This process ensures that the model learns from actual past behavior rather than just theoretical expectations.

Subsequently, the forecasting model integrates this historical event attendance data with its generalized time-series forecasting to produce a more accurate overall prediction. For rooms specifically designated for scheduled events, the system will weigh the historical attendance patterns of similar events alongside general occupancy trends. This blending process can be conceptualized as combining different models, such as a “raw forecasting model” and an “event-driven forecasting model,” to provide a more accurate and comprehensive forecast. For example, the system might blend the general ARIMA forecast with specific historical event data, potentially using a weighting scheme where, for instance, 70% of the prediction comes from the general forecast and 30% from event-specific historical data.

Once this refined, blended forecast is generated, it is then stored within the system and subsequently utilized to inform critical building management decisions, including adjustments to HVAC settings and the allocation of various resources. This systematic integration of scheduling data significantly contributes to more accurate predictions of room occupancy, particularly during scheduled events. By combining both historical event attendance data and broader generalized forecasting, the system effectively accounts for the unique impact that different types of events have on room occupancy. This sophisticated approach empowers facility managers to better anticipate and respond to specific space utilization needs, thereby optimizing resource deployment and ensuring that spaces are managed with maximum efficiency based on their expected usage.

Building on the refined and blended occupancy forecasts, the system then moves to the next phase of integrating these predictions with Building Management Systems (BMS) to optimize environmental controls such as heating, ventilation, and air conditioning (HVAC). This integration primarily leverages the BACnet protocol, a widely supported standard across BMS, though other similar APIs can also be employed depending on the specific system in place. The overarching objective is to dynamically adjust HVAC set points based on anticipated occupancy data, thereby enhancing energy efficiency while simultaneously maintaining optimal environmental conditions for occupants.

The integration of occupancy predictions with the BMS follows a structured data flow and decision-making process, which starts with generating occupancy forecasts and culminates in either automated or manual adjustments to HVAC set points. This process involves several detailed steps, outlining how data is processed, how decisions are derived, and how actions are executed within the overall system.

Initially, the system predicts occupancy and identifies corresponding HVAC zones. This involves generating room occupancy forecasts for the next 24 hours at hourly intervals, utilizing both historical data and scheduled event information. These predictions are then stored in a dedicated occupancy_predictions table, which includes fields for timestamp, zone_id, and predicted_occupancy, with timestamp and zone_id forming the primary key. Each zone within the system is linked to an HVAC system set point using unique identifiers. This linkage is maintained in a zone_to_hvac_link table, which maps a zone_id to an hvac_system_id and a set_point_id. This table also allows for a manual_override_level and a boost_value, providing flexibility for users to manually adjust desired set points or add an increment to predicted occupancy for finer control, thereby enabling the system to execute precise control commands based on the predicted occupancy.

Furthermore, the system is designed to incorporate CO2 sensor data into the decision-making process to further refine HVAC set point adjustments. CO2 levels are recognized as a strong indicator of both air quality and occupancy, thus influencing the ultimate decision on which set point to apply. CO2 sensor readings are stored in a co2_sensor_data table, linked to their respective zones, and analyzed to determine if additional ventilation is required, even when occupancy levels might otherwise seem low. This table tracks sensor_id, zone_id, timestamp, and co2_level. The ability to ingest CO2 sensor data adds to the decision-making engine, factoring in existing hardware sensors alongside the primary Wi-Fi data.

The system then proceeds to retrieve and categorize HVAC set points from the BMS using the BACnet protocol. These set points correspond to various operational levels, typically ranging from 0% (off) to 100% capacity, in increments such as 25%, 50%, and 75%, though these intervals can be adjusted to meet specific requirements. A BACnet query, for instance, can read the presentValue of analogValue objects to retrieve all current set points for controllable HVAC zones. The retrieved set points are then stored in an hvac_set_points table, categorized by their operational levels and linked back to their corresponding zones, tracking the hvac_system_id, set_point_id, operational_level, current_value, and last_updated timestamp.

Following the comprehensive process of integrating predicted occupancy with building management systems, the system is designed to automatically adjust HVAC set points based on the predicted occupancy for each zone. This step involves determining the appropriate set points by mapping predicted occupancy levels to corresponding HVAC operational levels, such as 0% (off), 25%, 50%, 75%, and 100% capacity, always ensuring to round up to the next highest set point to guarantee adequate ventilation.

To precisely calculate the appropriate set point, the system considers several factors: the predicted occupancy, any manual override settings, and any boost values that may be applied. For instance, if the predicted occupancy is 35%, a manual override is set to 50%, and a boost value of 10% is applied, the final effective occupancy considered by the system would be 45% (35%±10%). In this scenario, the system would then apply the 50% capacity set point, rounding up from 45% to ensure sufficient environmental control. Once the new set point is determined, a BACnet command is utilized to adjust the HVAC set point for the specific zone, such as setting zone_101 to 50% capacity.

The system diligently logs all set point adjustments, regardless of whether an actual change was made. These logs capture detailed information including the current and target set points, the predicted occupancy that informed the decision, relevant CO2 levels, and the operational level selected. This comprehensive logging is stored in an hvac_adjustment_logs table, which includes fields such as adjustment_id, timestamp, zone_id, hvac_system_id, previous_value, new_value, predicted_occupancy, co2_level, manual_override, and boost_applied. This detailed tracking allows the system to monitor HVAC behavior over time and calculate potential energy savings achieved from operating at reduced operational levels when appropriate.

Following the calculation and initial adjustment of set points, the system employs a decision tree to further refine the appropriate HVAC set point, taking into account a combination of calculated occupancy, CO2 levels, any manual override settings, and boost values. This structured decision-making process ensures that environmental controls are precisely tailored to the dynamic needs of each zone. In ope example, if the predicted occupancy combined with any boost value exceeds 75%, the system immediately sets the HVAC to 75% capacity. Alternatively, if the CO2 level surpasses 1000 ppm, signaling a potential air quality concern, the system is designed to increase the set point by one level above the calculated occupancy level to enhance ventilation. If these conditions are not met but the current occupancy plus any boost is still above 50%, the system will then apply a 50% capacity set point. Should none of these higher occupancy or CO2 thresholds be met, the system defaults to a 25% capacity set point or will turn off the HVAC entirely if occupancy falls below a predetermined threshold. Other examples can also be implemented.

To ensure transparency and facilitate continuous improvement, every decision made by the system is meticulously logged for future analysis, whether the adjustment was automated or influenced by CO2 levels or manual overrides. These decision outcomes are stored in a dedicated decision_logs table, which includes comprehensive details such as a decision_id, timestamp, zone_id, the predicted_occupancy at the time of the decision, the co2_level, the selected_set_point, and a decision_reason. This detailed logging not only records the logic behind each control decision but also enables a thorough review of the system's functioning and helps identify valuable opportunities for further optimization of HVAC operations and energy savings.

Ultimately, this integrated process systematically links predicted occupancy data with HVAC systems through the BACnet protocol, dynamically adjusting set points to achieve optimal energy usage while maintaining comfortable conditions for occupants. By incorporating CO2 sensor data, alongside manual overrides and boost values, into its decision-making framework, the system ensures that HVAC operations are both highly efficient and responsive to actual environmental conditions. The comprehensive logging of all actions and decisions provides invaluable insights into energy savings and overall operational efficiency, establishing the system as a powerful and advanced tool for modern building management.

The system described above presents a revolutionary approach to building management by seamlessly integrating advanced occupancy forecasting, real-time sensor data, and dynamic control of HVAC systems. One of the system's most beneficial aspects is the ability to predict room occupancy with high accuracy by leveraging both historical usage patterns and real-time scheduling data. This predictive capability is further enhanced by incorporating CO2 sensor data, which allows for more precise control of air quality and ventilation. The system's use of the BACnet protocol, alongside other similar APIs, enables it to adjust HVAC set points dynamically based on actual and anticipated occupancy levels, scaling from 0% to 100% capacity with fine-tuned increments. Unlike traditional systems that operate in an “all or nothing” manner, this solution intelligently adjusts the environmental controls to match the exact needs of the space, resulting in significant energy savings.

One differentiator of this system is its ability to accommodate manual overrides and boost values, allowing users to prioritize air quality or comfort in specific zones without resorting to full-capacity operations. Furthermore, the system maintains a robust linkage between zones and HVAC systems, ensuring continuity and precision even as naming conventions or configurations change over time. The comprehensive logging of all adjustments and decisions provides an invaluable dataset for calculating energy savings and refining operational strategies. This combination of predictive analytics, real-time data integration, and adaptive control makes the system a game-changer in building management, offering unparalleled efficiency, flexibility, and sustainability.

Another aspect of the disclosed system relates to its use with geothermal loops, benefiting from the system's advanced occupancy forecasting capabilities. Generally, a geothermal loop is a component of a geothermal heating and cooling system that utilizes the Earth's stable underground temperature to regulate building temperatures. In a typical geothermal system, water is transferred from one place to another and can take time. For example, it can take four hours for water to go through an entire geothermal loop. The disclosed system's ability to predict, four hours ahead of time, where people will be at a given time, derived from its utilization of Wi-Fi data, scheduling information, and machine learning algorithms, provides a beneficial input for optimizing the geothermal system. This proactive prediction enables the system to better optimize whether to discard energy or transfer energy through that geothermal loop. At a building level, this predictive data can be used to adjust the building level controls, such as dynamically altering HVAC set points based on anticipated occupancy, just as described for other environmental controls. Concurrently, at the geothermal loop level, this same predictive data can be used to optimize the geothermal loop itself, ensuring efficient energy management across the entire facility by anticipating future demand.

FIG. 1 is an example architecture diagram illustrating the system's components and their interactions. The system is designed for optimizing HVAC systems in large institutions by providing improved environmental control input data for a Building Management System (BMS), as described in detail above. FIG. shows how the system integrates with existing building infrastructure to determine and predict building occupancy more accurately and in real-time. The depicted components include a main application (102), a configuration manager (104), a data compiler/updater (106), a BACnet server (108), and an API client (110). The main application (102) represents the core of the system, interacting with the other components to process Wireless Local Area Networking (WLAN) data, forecast occupancy, and generate environmental control set point data. The data compiler/updater (106) processes and combines calculated values, such as real-time and forecasted occupancy counts, which are then communicated to the external BMS through either the BACnet server (108), utilizing the standard BACnet protocol, or the API client (110). This architecture enables the system to leverage wireless presence data, integrate scheduling data, and employ predictive analytics to achieve its objectives.

FIG. 2 is a sequence diagram that illustrates the operation of the invention, specifically detailing the flow of occupancy data from collection to integration with a building management system. The process begins with a scheduler component (202), which periodically triggers a poll (e.g., every 10 minutes), to initiate data fetching. An API client (204) then fetches occupancy data from an external DegreeAnalyticsAPI (210), which previously exposed occupancy values and is a REST API system. Once the occupancy data is returned to the API client (204), it is passed to a data compiler/updater (206). This data compiler/updater (206) processes and combines calculated values, such as real-time and forecasted occupancy counts. Subsequently, the data compiler/updater (206) updates BACnet object values within a BACnet server (208). The external building management system (BMS) (209) can then interact with the BACnet server (208), initiating communication with a “Who-is” request, to which the BACnet server (208) responds with an “I-Am” message. The building management system (209) then sends a “ReadProperty” request to the BACnet server (208) to retrieve specific data, and the BACnet server (208) provides a “ReadProperty response.” This sequence demonstrates how the system continuously gathers, processes, and transmits real-time and forecasted occupancy data to the building management system, enabling dynamic adjustments to environmental controls.

FIG. 3 is a flowchart illustrating a method for generating environmental control input data for a building management system (BMS) in a building, according to various embodiments. The method begins with a computing system receiving wireless local area networking (WLAN) data (302) from multiple wireless access points (APs) located within the building, where this WLAN data is associated with various user devices present across different zones of the building. Subsequently, the computing system processes this WLAN data to accurately determine a real-time occupancy count for each of these distinct zones within the building (304). Building on this real-time data, the computing system then forecasts a future occupancy count (306) for each of the zones for an upcoming time period. This forecasting is performed using machine learning algorithms and is based on a comprehensive analysis of historical WLAN data, historical utilization data, and scheduled event data pertinent to each zone. Finally, the computing system generates environmental control set point data (308) for the building management system, utilizing both the determined real-time occupancy count and the forecasted future occupancy count for each of the different zones to optimize environmental conditions and energy usage.

FIG. 4 depicts a diagrammatic representation of a data processing system for implementing systems and methods for determining and predicting building occupancy disclosed herein. As shown in FIG. 4, data processing system (1200) may include one or more central processing units (CPU) or processors (1201) coupled to one or more user input/output (I/O) devices (1202) and memory devices (1203). Examples of I/O devices (1202) may include, but are not limited to, keyboards, displays, monitors, touch screens, printers, electronic pointing devices such as mice, trackballs, styluses, touch pads, or the like. Examples of memory devices (1203) may include, but are not limited to, hard drives (HDs), magnetic disk drives, optical disk drives, magnetic cassettes, tape drives, flash memory cards, random access memories (RAMs), read-only memories (ROMs), smart cards, etc. Data processing system (1200) can be coupled to display (1206), information device (1207) and various peripheral devices (not shown), such as printers, plotters, speakers, etc. through I/O devices (1202). Data processing system (1200) may also be coupled to external computers or other devices through network interface (1204), wireless transceiver (1205), or other means that is coupled to a network such as a local area network (LAN), wide area network (WAN), or the Internet.

Although the invention has been described with respect to specific embodiments thereof, these embodiments are merely illustrative, and not restrictive of the invention as a whole. Rather, the description is intended to describe illustrative embodiments, features and functions in order to provide a person of ordinary skill in the art context to understand the invention without limiting the invention to any particularly described embodiment, feature or function, including any such embodiment feature or function described in the Abstract or Summary. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes only, various equivalent modifications are possible within the spirit and scope of the invention, as those skilled in the relevant art will recognize and appreciate. As indicated, these modifications may be made to the invention in light of the foregoing description of illustrated embodiments of the invention and are to be included within the spirit and scope of the invention.

Thus, while the invention has been described herein with reference to particular embodiments thereof, a latitude of modification, various changes and substitutions are intended in the foregoing disclosures, and it will be appreciated that in some instances some features of embodiments of the invention will be employed without a corresponding use of other features without departing from the scope and spirit of the invention as set forth. Therefore, many modifications may be made to adapt a particular situation or material to the essential scope and spirit of the invention.

Software implementing embodiments disclosed herein may be implemented in suitable computer-executable instructions that may reside on a computer-readable storage medium. Within this disclosure, the term “computer-readable storage medium” encompasses all types of data storage medium that can be read by a processor.

Examples of computer-readable storage media can include, but are not limited to, volatile and non-volatile computer memories and storage devices such as random access memories, read-only memories, hard drives, data cartridges, direct access storage device arrays, magnetic tapes, floppy diskettes, flash memory drives, optical data storage devices, compact-disc read-only memories, hosted or cloud-based storage, and other appropriate computer memories and data storage devices.

Those skilled in the relevant art will appreciate that the invention can be implemented or practiced with other computer system configurations including, without limitation, multi-processor systems, network devices, mini-computers, mainframe computers, data processors, and the like. The invention can be employed in distributed computing environments, where tasks or modules are performed by remote processing devices, which are linked through a communications network such as a LAN, WAN, and/or the Internet. In a distributed computing environment, program modules or subroutines may be located in both local and remote memory storage devices. These program modules or subroutines may, for example, be stored or distributed on computer-readable media, including magnetic and optically readable and removable computer discs, stored as firmware in chips, as well as distributed electronically over the Internet or over other networks (including wireless networks).

Embodiments described herein can be implemented in the form of control logic in software or hardware or a combination of both. The control logic may be stored in an information storage medium, such as a computer-readable medium, as a plurality of instructions adapted to direct an information processing device to perform a set of steps disclosed in the various embodiments. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and/or methods to implement the invention. At least portions of the functionalities or processes described herein can be implemented in suitable computer-executable instructions. The computer-executable instructions may reside on a computer readable medium, hardware circuitry or the like, or any combination thereof.

Any suitable programming language can be used to implement the routines, methods or programs of embodiments of the invention described herein, including C, C++, Java, JavaScript, HTML, or any other programming or scripting code, etc. Different programming techniques can be employed such as procedural or object oriented. Other software/hardware/network architectures may be used. Communications between computers implementing embodiments can be accomplished using any electronic, optical, radio frequency signals, or other suitable methods and tools of communication in compliance with known network protocols.

As one skilled in the art can appreciate, a computer program product implementing an embodiment disclosed herein may comprise a non-transitory computer readable medium storing computer instructions executable by one or more processors in a computing environment. The computer readable medium can be, by way of example only but not by limitation, an electronic, magnetic, optical or other machine readable medium. Examples of non-transitory computer-readable media can include random access memories, read-only memories, hard drives, data cartridges, magnetic tapes, floppy diskettes, flash memory drives, optical data storage devices, compact-disc read-only memories, and other appropriate computer memories and data storage devices.

Particular routines can execute on a single processor or multiple processors. Although the steps, operations, or computations may be presented in a specific order, this order may be changed in different embodiments. In some embodiments, to the extent multiple steps are shown as sequential in this specification, some combination of such steps in alternative embodiments may be performed at the same time. The sequence of operations described herein can be interrupted, suspended, or otherwise controlled by another process, such as an operating system, kernel, etc. Functions, routines, methods, steps and operations described herein can be performed in hardware, software, firmware or any combination thereof.

It will also be appreciated that one or more of the elements depicted in the drawings/figures can be implemented in a more separated or integrated manner, or even removed or rendered as inoperable in certain cases, as is useful in accordance with a particular application. Additionally, any signal arrows in the drawings/figures should be considered only as exemplary, and not limiting, unless otherwise specifically noted.

As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having,” or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, product, article, or apparatus that comprises a list of elements is not necessarily limited only those elements but may include other elements not expressly listed or inherent to such process, product, article, or apparatus.

Furthermore, the term “or” as used herein is generally intended to mean “and/or” unless otherwise indicated. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present). As used herein, a term preceded by “a” or “an” (and “the” when antecedent basis is “a” or “an”) includes both singular and plural of such term, unless clearly indicated within the claim otherwise (i.e., that the reference “a”or “an”clearly indicates only the singular or only the plural). Also, as used in the description herein and throughout the meaning of “in” includes “in” and “on”unless the context clearly dictates otherwise.

Additionally, any examples or illustrations given herein are not to be regarded in any way as restrictions on, limits to, or express definitions of, any term or terms with which they are utilized. Instead, these examples or illustrations are to be regarded as being described with respect to one particular embodiment and as illustrative only. Those of ordinary skill in the art will appreciate that any term or terms with which these examples or illustrations are utilized will encompass other embodiments which may or may not be given therewith or elsewhere in the specification and all such embodiments are intended to be included within the scope of that term or terms. Language designating such nonlimiting examples and illustrations includes, but is not limited to: “for example,” “for instance,” “e.g.,” “in one embodiment.”

In the description herein, numerous specific details are provided, such as examples of components and/or methods, to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that an embodiment may be able to be practiced without one or more of the specific details, or with other apparatus, systems, assemblies, methods, components, materials, parts, and/or the like. In other instances, well-known structures, components, systems, materials, or operations are not specifically shown or described in detail to avoid obscuring aspects of embodiments of the invention. While the invention may be illustrated by using a particular embodiment, this is not and does not limit the invention to any particular embodiment and a person of ordinary skill in the art will recognize that additional embodiments are readily understandable and are a part of this invention.

Generally then, although the invention has been described with respect to specific embodiments thereof, these embodiments are merely illustrative, and not restrictive of the invention. Rather, the description is intended to describe illustrative embodiments, features and functions in order to provide a person of ordinary skill in the art context to understand the invention without limiting the invention to any particularly described embodiment, feature or function, including any such embodiment feature or function described. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes only, various equivalent modifications are possible within the spirit and scope of the invention, as those skilled in the relevant art will recognize and appreciate.

As indicated, these modifications may be made to the invention in light of the foregoing description of illustrated embodiments of the invention and are to be included within the spirit and scope of the invention. Thus, while the invention has been described herein with reference to particular embodiments thereof, a latitude of modification, various changes and substitutions are intended in the foregoing disclosures, and it will be appreciated that in some instances some features of embodiments of the invention will be employed without a corresponding use of other features without departing from the scope and spirit of the invention as set forth. Therefore, many modifications may be made to adapt a particular situation or material to the essential scope and spirit of the invention.