Skip to content

Latest commit

 

History

History
45 lines (37 loc) · 3.39 KB

README.md

File metadata and controls

45 lines (37 loc) · 3.39 KB
Raw

Building Control Test Framework

This repository contains prototype code for the Building Fault & CyberAttack Test Framework

Structure

  • /model contains model dependencies, model files and default configuration files
  • /examples contains examples about how to use different Application Programming Interface (APIs)

Quick-Start to Run Test Cases

  1. Install Docker and [make](Window: http://gnuwin32.sourceforge.net/packages/make.htm; Linux: sudo apt-get install build-essential; Mac: https://stackoverflow.com/questions/11494522/installing-make-on-mac/11494872).
  2. Clone this repo with git clone --recurse-submodules https://github.com/SenHuang19/AFDD_test.
  3. Build the test case by $ make build
  4. Deploy the test case by $ make run
  5. In a separate process, use the APIs to interact with the Docker.
  6. Shutdown a Docker with Ctrl+C to close port, and Ctrl+D to exit the Docker container.
  7. Remove the Docker container by $ docker rm jmodelica.
  8. Remove the Docker image by $ make remove-image.

Test Case RESTful API

  • To interact with a deployed test case, use the API defined in the table below by sending RESTful requests to: http://127.0.0.1:5000/<request>

    Example RESTful interaction: -- Receive a list of available measurement names and their metadata: $ curl http://127.0.0.1:5000/measurements

Interaction Request
Advance simulation with control input and receive measurements POST advance with json data "{<input_name>:}"
Initialize simulation using a warmup period in seconds PUT reset with arguments start_time=<value>, end_time=<value>
Receive communication step in seconds GET step
Set communication step in seconds PUT step with argument step=<value>
Receive sensor signal names (y) and metadata GET measurements
Receive control signals names (u) and metadata GET inputs
Receive test result data GET results

Key Points

The key points for the testing model (AHU) is discussed in /model/fmu/fault.json. Those points can be categorized in three groups and have three properties: path, description, and type. The path defines the location of the corresponding fault in the studied model. The description defines the location of the corresponding fault in the system that the studied model represent. The type defines the type of this key point. Types of key points are defined in /model/fmu/config.json and are independent of the test model.