Framework

Technical documentation of the Phoenix Contact Emalytics Control framework.

Reliability and robust control¶

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 Emalytics Connectors 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 or a MQTT message with a payload, structured according to SWOP.
The Emalytics Connectors 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.

Safety features¶

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 Emalytics Control 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 Emalytics Control 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 Emalytics Connectors 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.

Communication protocol¶

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¶

Phoenix Contact Emalytics Control and Emalytics Analyzer 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.

Phoenix Contact Emalytics Control library¶

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.

Place of implementation¶

Phoenix Contact Emalytics Control enables remote and cloud control. Moreover, Phoenix Contact tailors edge control solutions if required. See the schematic below for a basic differentiation of these control concepts.

Remote control

Using the remote control functionalities, you can directly operate local plants via the Emalytics Collector platform, e.g. by self-hosted control algorithms, by control functionalities or even manually via API.

Cloud control

Phoenix Contact Emalytics Control features various control algorithms that we operate within the Emalytics Collector platform. See section control algorithms for an introduction of available control algorithms.

As a custom service, Phoenix Contact 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.

Edge control

In edge control, control algorithms run directly on the Emalytics Connector. This accounts for low communication latency. At the same time, it lowers the risks of down-times due to communication issues between the Emalytics Connector and the cloud.

Deployment scenarios¶

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 Emalytics Connector 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.