Technical documentation of the aedifion.controls framework.
Reliability and robust control¶
Figure 1: Edge Device communication schematic
The energy systems of a building are essential and must function properly 24 hours a day, 365 days a year. They need to be able to function robustly and withstand communication issues and sensor outages by possessing reliable fallback strategies. Our Edge Devices are equipped with state-of-the-art algorithms able to detect all of these issues and resetting cloud-based control algorithms, handing over the control responsibilities to the locally implemented automation system. This way, we can ensure that whatever happens, the building will continue to operate reliably.
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 2: 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. 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¶
aedifion.controls and aedifion.analytics make use of component models. In .controls, the component 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 it is 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 temp and Opening (of the valve in the circuit). The circuit model also contains a pin for the Return temp and the PID model contains a further optional pin for the controller state, namely the Int. error, which can also be private in the virtual data point.
Figure 3: Connection of controller and plant models
The library can be used to create custom control applications. In the following, we introduce general control functionalities. For in-depth information on the offered control algorithms .
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 4: 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 5: 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.