Supervisory control algorithms, saving energy and improving the indoor climate and overall comfort.
.controls is our control framework for the development and execution of supervisory algorithms that autonomously optimize the operation of technical building equipment and energy supply systems. Thus, .controls enables predictive and economic optimization with minimal interventions in the local control systems of the assets. With the help of AI-based control modules from the .controls library, you can efficiently develop powerful cloud-based control. For secure communication with the assets, you can use the .io cloud platform and .controls data structuring to scale generic algorithms to a variety of heterogeneous properties.
Control signal flow¶
The signal flow is depicted in Figure 1. A control application (app) sends commands to our API (check out the relevant API endpoints for a detailed description) or a MQTT message with a payload, structured according to SWOP.
The Edge Devices subscribing to the topic receive the message. They write the values to the automation devices and publish an acknowledge message that includes information such as success and failure of the writing procedure.
Figure 1: Signal flow
As writing commands to an automation system must ensure the system's safe operation at all times, the following safety features are part of the .controls framework.
- limit check: The API returns an error code if the value of the command is out of the pre-defined range.
- priorities: In BACnet systems, the priority array allows overriding commands in cases of emergency. Each command sent using .controls is sent with a priority, per default the lowest available (16).
- acknowledgments: To ensure that the automation system is always in a known state, the Edge Devices allow tracking if a command was successfully written to an automation device.
- Alarms: Setting an alarm ensures that a user is notified immediately if a measurement quantity in the automation system shows unexpected behavior due to control action.
Each MQTT message that is published for sending a command to the automation system contains a value and a unique identifier of the datapoint to write to. Moreover, it contains a priority that is used in BACnet systems. Check out the detailed message description of the SWOP protocol.
Component and controller data models¶
Component data models contain writable pins and read-only pins that are connected to the data points belonging to a certain plant in the automation system or a certain controller in .controls. The use of such data models is not mandatory but recommended as it facilitates the control design.
Controller data models have a subset of the plant's pins and further controller-specific pins. Some of the pins are connected to virtual data points. The following figure shows an example with a hydraulic circuit that is to be controlled by a proportional-integral-derivative (PID) controller. Both the controller and the circuit have a data model and both models are connected via the pins flow temperature and opening (of the valve in the circuit). The circuit model also contains a pin for the return temperature and the PID model contains a further pin for the controller state, namely the integrated error.
Figure 2: Connection of controller and plant models
The library allows for creating custom control applications. In the following, we introduce general control functionalities. For in-depth information on the offered control algorithms, visit control specifications
Control algorithms are defined as automatically generated actions with feedback usage.
In the meaning of the classic control theory, control algorithms are defined as closed-loop control systems. Find a schematic diagram of such a system below. The difference between the feedback of the controlled system and the setpoint is the input to the system's controller. The generated algorithm's output is the input to the controlled system.
Figure 3: Closed-loop control system to explain the concept of control algorithms
Place of implementation¶
aedifion.controls enables remote and cloud control. Moreover, aedifion tailors edge control solutions if required. See the schematic below for a basic differentiation of these control concepts.
Figure 4: Differentiation of control concepts
Using the remote control functionalities, you can directly operate local plants via the aedifion.io platform, e.g. by self-hosted control algorithms, by control functionalities or even manually via API.
aedifion.controls features various control algorithms that we operate within the aedifion.io platform. See section control algorithms for an introduction of available control algorithms.
As a custom service, aedifion deploys and hosts your proprietary control algorithms as cloud control algorithms. It is now possible to easily manage your estate and buildings in order to realize an overall demand-side management. Please do not hesitate to contact us to discuss your needs.
In edge control, control algorithms run directly on the aedifion Edge Device. This accounts for low communication latency. At the same time, it lowers the risks of down-times due to communication issues between the Edge Device and the cloud.
Control algorithms can be operated in different ways. A cloud-operated algorithm uses the internet to communicate its control decisions or manipulated variables. Contrarily, an edge-operated algorithm is executed locally on the aedifion.io Edge Device within the customer's control system and only requires internet connectivity to receive commands and updates. An air-gapped deployment is a more classical set-up, quite like a local programmable logic controller, but with a more advanced control runtime, offering the possibility to execute more complex controls, including optimizations and simulations.