> For the complete documentation index, see [llms.txt](https://docs.voltmasters.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.voltmasters.io/dso-rtu/how-telecontrole-works.md).

# How DSO RTU works

### The chain

A DSO RTU command travels through a well-defined chain:

```
Grid operator control centre
        │   (operator's private network)
        ▼
   RTU on site  ──────────────►  Voltmasters EMS  ──────────────►  Assets
   (grid operator)   DSO RTU         (controller)     Modbus/...     (PV, ESS, EV, loads)
        ◄──────────────  feedback & measurements  ◄──────────────
```

1. The grid operator decides on a limit or action in its control centre.
2. The command is sent to an **RTU** (Remote Terminal Unit) installed on site by the grid operator.
3. The RTU communicates with the **Voltmasters EMS** over a standardized DSO RTU protocol. The specific protocol depends on the grid operator. See [RTU connection](/dso-rtu/rtu-connection.md).
4. The EMS translates the command into concrete actions on the connected assets, every control cycle (≈ 1 second).
5. The EMS continuously reports back the actual state and measurements, so the grid operator can verify compliance.

### What the EMS receives

Each control cycle the EMS turns the latest DSO RTU state into a set of **constraints** that are applied to the installation:

### Active power (P) limits

| Limit                                       | Meaning                                                                       |
| ------------------------------------------- | ----------------------------------------------------------------------------- |
| **Max injection at the connection point**   | Cap on power injected into the grid, as a % of the contractual grid capacity. |
| **Max consumption at the connection point** | Cap on power drawn from the grid, as a % of the contractual grid capacity.    |
| **Max asset production**                    | Cap on total production, as a % of installed asset power.                     |
| **Max asset consumption**                   | Cap on total consumption, as a % of installed asset power.                    |

### Reactive power (Q) control

* **Q control mode**: *local* (the EMS manages reactive power itself) or *remote* (the EMS applies the grid operator's reactive power band).
* **Reactive power band**: a minimum and maximum Q the installation must stay within when in remote mode.

### Emergency stops

* **Emergency stop production**: no injection is allowed: PV is switched off and battery discharge is stopped.
* **Emergency stop consumption**: no consumption is allowed: battery charging is stopped and controllable loads are switched off.

Emergency stops are the **highest-priority** constraint and can additionally drive a physical relay (see [IO module emergency stop](/dso-rtu/io-module-emergency-stop.md)).

### Reason codes

Every active-power and reactive-power control carries a **reason**: normal operation, **grid congestion**, or **test**. The test reason is used during the grid operator's certification (see [Commissioning & certification](/dso-rtu/commissioning-and-certification.md)).

### How the EMS applies the constraints

DSO RTU constraints are applied inside the EMS control loop **after** local/manual overrides but **before** the grid-protection limits, so that:

* operator commands always take precedence over local optimization, and
* the EMS never violates the physical grid connection limits.

When power has to be reduced, the EMS curtails in a deliberate order to protect equipment and value:

* **For a production limit:** reduce battery discharge first, then reduce PV.
* **For a consumption limit:** reduce battery charging.
* **For reactive power:** distribute the required Q across the capable assets (batteries and PV), respecting each device's apparent-power rating.

{% hint style="info" icon="lightbulb" %}
Because the loop runs every ≈ 1 second, the installation follows a DSO RTU command with sub-second to a few seconds latency, depending on how fast the assets themselves can ramp.
{% endhint %}

### Feedback and measurements

The link is bidirectional. The EMS:

* **Confirms** every received command immediately.
* **Mirrors** the resulting state back to the grid operator (the limits, modes and emergency-stop states that are in effect).
* Sends **periodic measurements** (every 30 seconds) of actual active and reactive power, grouped per **asset category** (solar, storage, EV, …).

This closes the loop: the grid operator does not just send commands, it can independently verify that the installation complies.

### Enforcement layers

| Layer                    | Always active?                | What it does                                                                                |
| ------------------------ | ----------------------------- | ------------------------------------------------------------------------------------------- |
| **Software**             | Yes                           | Curtails assets in the control loop (setpoints to zero, batteries disconnected, loads off). |
| **Hardware (IO module)** | Optional, for emergency stops | Drives one or more relays wired to the installation's physical emergency-stop circuit.      |

The software layer guarantees a correct response in all normal situations. The hardware layer adds a physical, asset-independent emergency stop for installations that require it (see [IO module emergency stop](/dso-rtu/io-module-emergency-stop.md)).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.voltmasters.io/dso-rtu/how-telecontrole-works.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.