Skip to content

UseCases

Jump to bottom
dhblum edited this page Aug 30, 2018 · 2 revisions

This page lists a use case for an end-user and a developer.

Client

The client represents the user who is testing a controller that they have developed on a BOPTEST test case. The client will:

  1. Download and install boptest runtime platform. Establish connection through port mapping per installation instructions.
  2. Through a defined runtime platform API, select a test case from available test cases. The runtime platform will download and deploy the appropriate test case docker image.
  3. Through a defined runtime platform API, retrieve information about the test, such as available control signals, measurements, communication steps, and forecasts (e.g. weather for MPC).
  4. Through a defined runtime platform API, set the communication step size, in simulated seconds, with the test case or set the test case to advance according to the wall clock.
  5. Link the controller to be tested to the test case through a defined controller API, which may be different than the runtime platform API (e.g. Haystack or custom).
  6. Through a defined runtime platform API, initiate the test and run to completion, exchanging measurement, forecast, and updated control signal data at every communication step.
  7. Receive report of KPI results for test from runtime platform upon completion of test.
  8. Through a defined runtime platform API, receive other data collected during test, such as control signal or measurement trajectories, for further post processing.
  9. Through a defined runtime platform API, manage available test cases and proceed back to Step 2.

Test Case Developer

The test case developer represents the user who is creating test case emulator models, defining control signals and measurements, setting simulation options (such as solver, tolerance, available communication steps), and writing KPI calculations. The test case developer will:

  1. Create the test case Modelica model in a local computing environment according to the specifications and template outlined in the requirements document.
  2. Include any required exogenous input data, such as weather files or occupancy schedules, defined outside of the model.
  3. Peer review test case model.
  4. Finalize test of the simulation of the FMU with exogenous input data locally.
  5. Use template script to build docker image from FMU of model and exogenous input data representing test case.
  6. Post docker image to BOPTEST test case repository.
Clone this wiki locally