Giter Club home page Giter Club logo

constrain's Introduction

Control Strainer (ConStrain): A Data-driven Control Verification Framework (formally known as ANIMATE)

Unit tests status: Tests

Background and Motivation

Advances in building control have shown significant potential for improving building energy performance and decarbonization. Studies show that designs utilizing optimized controls that are properly tuned could cut commercial building energy consumption by approximately 29% - equivalent to 4-5 Quads, or 4-5% of the energy consumed in the United States. Driven by the significant control-related energy-saving potential, commercial building energy codes (such as ASHRAE 90.1) have progressed with many control-related addenda. For example, from the publication of 90.1-2004 to 90.1-2016 (four code cycles), 30% of the new requirements are related to building control (with most of them focused on HVAC system control).

However, one of the challenges to realizing those savings is the correct implementation of such advanced control strategies and regularly verifying their actual operational performance. A field study found that only 50% of systems observed have their control system correctly configured to meet the energy codes requirement, and control-related compliance verification is typically not included in the commissioning (Cx) scope. The current control verification is often manually conducted, which is time-consuming, ad-hoc, incomplete, and error-prone.

What is ConStrain?

ConStrain is a data-driven knowledge-integrated framework that automatically verifies that controls function as intended. The figure below shows an overview of ConStrain and how it can be used. ConStrain was born out of the need of automating the verification of time-series data describing the behavior of building components, especially the control functions.

ConStrain is designed around three key features: building control knowledge integration, analytics, and automation. The framework includes three major components: a control verification algorithm library (rule-based, procedure-based, and AI-based), an automated preparation process and verification case generation, a standardized performance evaluation and reporting process.

While the development of ConStrain was motivated by use cases with building energy modeling (BEM), it is now evolved for more application scenarios towards real building control verification.

Overview of ConStrain

Who shall be interested in this framework?

  • Cx agent – reduce effort and cost, while increasing rigor.
  • Building operator – implement Continuous Commissioning (CCx) to avoid performance drift.
  • Authority having jurisdiction (AHJ) – achieve better compliance rates for control provisions in code.
  • Mechanical engineer/energy modeler – ensure that chosen systems and their controls will comply with code.
  • Energy code/control guideline developer – identify ambiguity in code languages.
  • BEM software developer – identify control related issues in simulation engine.

Current Version of ConStrain?

The current version of ConStrain includes the framework implementation, a preliminary development and implementation of the verification library (based on ASHRAE 90.1-2016 control related requirement), and the test cases of verification algorithms using prototype building models. The current list of implemented verification algorithms includes supply air temperature control, economizer high limit, integrated economizer control, zone temperature control (dead band), zone temperature control (setback), hot water temperature reset, chilled water temperature reset, etc.

A newly released API helps users to use ConStrain more easily. An API workflow demo is provided at demo/api_demo and test/api/test_workflow.py

See the Publications section for more information and example of uses of the framework.

Get Started

Publications

Referencing

If you wish to cite ConStrain in academic work please use: Lei, X., Lerond, J., Jung, Y. J., & Chen, Y. (2023). ConStrain (Version 0.4.0) [Computer software]. https://github.com/pnnl/ConStrain

constrain's People

Contributors

jslane-h avatar leijerry888 avatar lymerej avatar yanchenpnnl avatar yunjoonjung-pnnl avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

constrain's Issues

Move `output` out of the `simulation_IO` dictionary

Currently, output is included in the simulation_IO dictionary of verification items. This makes sense for simulation-based verifications but not for verifications relying solely on CSV files for verifications, for instance coming out of a BAS. output should probably also be renamed to something like data_path or path_to_data to clearly state what its general purpose is.

"output": "./demo/G36_demo/data/G36_Modelica_Jan.csv",

Consolidate the `demo` and `test_cases` folders

Having a test_cases and demo folder is confusing, we should probably consolidate them and add the examples to the documentation and integrate them as part of the tests to make sure that subsequent changes to the code base doesn't prevent them from running.

Implement default tolerance values

@kimw821 developed the following default tolerance values. These should be implemented as default and overridden by users.

Point Label Value Reference
Temperature sensor tolerance 1.0 deg. F Automatic Identification of Retro-commissioning Measures, PNNL-27338, Section 2.2
Low supply fan threshold 20.0 % Automatic Identification of Retro-commissioning Measures, PNNL-27338, Section 2.2
Minimum MAT threshold 50.0 deg. F Automatic Identification of Retro-commissioning Measures, PNNL-27338, Section 2.2
Maximum MAT threshold 90.0 deg. F Automatic Identification of Retro-commissioning Measures, PNNL-27338, Section 2.2
Minimum OAT threshold 30.0 deg. F Automatic Identification of Retro-commissioning Measures, PNNL-27338, Section 3.3
Maximum OAT threshold 100.0 deg. F Automatic Identification of Retro-commissioning Measures, PNNL-27338, Section 3.3
Maximum RAT threshold 90.0 deg. F Automatic Identification of Retro-commissioning Measures, PNNL-27338, Section 3.3
Temperature difference tolerance 4.0 deg. F Automatic Identification of Retro-commissioning Measures, PNNL-27338, Section 3.3
Maximum damper position 100.0 % Automatic Identification of Retro-commissioning Measures, PNNL-27338, Section 3.3
Minimum damper position 10.0 % Automatic Identification of Retro-commissioning Measures, PNNL-27338, Section 3.3
OAF temperature tolerance 4.0 deg. F Automatic Identification of Retro-commissioning Measures, PNNL-27338, Section 3.3
Cooling enabled tolerance 5.0 deg. F Automatic Identification of Retro-commissioning Measures, PNNL-27338, Section 3.3
Desired OAF 10.0 % Automatic Identification of Retro-commissioning Measures, PNNL-27338, Section 3.3
Economizer high limit temperature RAT + 1.0 deg. F (DDB Economizer) ASHRAE Guideline 36-2021, High-Performance Sequences of Operation for HVAC Systems
Return air damper tolerance 5.0 % Engineering judgment
Maximum cooling SA temperature 75 deg. F Automatic Identification of Retro-commissioning Measures, PNNL-27338, Section 2.2
Minimum cooling SA temperature 50 deg. F Automatic Identification of Retro-commissioning Measures, PNNL-27338, Section 2.2
SA temperature tolerance 6.5 deg. F ASHRAE Guideline 36-2021, High-Performance Sequences of Operation for HVAC Systems
Economizer type Differential Dry-bulb (DDB) Engineering judgment

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.