# How DSO RTU works

> The end-to-end DSO RTU control model: from the grid operator's control centre to the assets in your installation, and back.

Source: https://voltmasters.io/en/docs/dso-rtu/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 DSO RTU protocol. The protocol, and which of the two sides opens the conversation, depend on the grid operator. See [RTU connection](https://voltmasters.io/en/docs/dso-rtu/rtu-connection/) and the operator's own page under [Grid operators](https://voltmasters.io/en/docs/dso-rtu/grid-operators/).
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. This constraint set is the EMS's own, operator-independent model, and it is what makes the asset side identical for every operator. No operator fills all of it: each one supplies the part its data model defines, in its own units, and the EMS converts.

> **Note**
>
> The tables below describe the **full** constraint set. Which entries an operator actually uses, and what a value means once it arrives, is on that operator's page under [Grid operators](https://voltmasters.io/en/docs/dso-rtu/grid-operators/).

### 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 the production of the registered assets, as a % of the reference power the operator registered for them. |
| **Max asset consumption** | Cap on the consumption of the registered assets, as a % of the reference power the operator registered for them. |

The percentages are the EMS's internal form. An operator that instructs in **absolute power** has its setpoint converted into the matching cap, so the enforced kW equals the ordered kW. An operator may also instruct only part of this set, or only one asset type at a time.

### Reactive power (Q) control

-   **Q control mode**: *local* (the EMS manages reactive power itself) or *remote* (the EMS follows the grid operator's reactive instruction).
-   **Reactive power band**: a minimum and maximum Q the installation must stay within, used by operators that instruct a band.
-   **Reactive power target**: a single absolute Q the installation must hold, used by operators that instruct an absolute value.
-   **Power factor target**: a cos φ the installation must hold, used by operators that instruct a power factor.

An operator that does not steer reactive power at all leaves the mode on *local*, and so does the EMS while an operator that can steer it has not instructed anything.

### Emergency stops

-   **Emergency stop production**: no injection is allowed: PV is switched off and the battery is set to 0 kW.
-   **Emergency stop consumption**: no consumption is allowed: the battery is set to 0 kW and controllable loads are switched off.

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

> **Warning**
>
> Not every operator has an emergency stop on its DSO RTU link. Where it is absent, decoupling on a grid fault is handled by the autonomous C10/21 protection in the installation, outside the EMS. Check the operator's page before relying on DSO RTU for safety decoupling.

### Reason codes

Where the operator's data model provides them, 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](https://voltmasters.io/en/docs/dso-rtu/commissioning-and-certification/)). Operators whose data model has no reason field send instructions without one.

### 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. An emergency stop is final for those protections; a percentage law can be loosened by them when the connection itself is about to overload, see [the order of the laws](https://voltmasters.io/en/docs/dso-rtu/grid-operators/fluvius/setpoint-processing/#the-order-of-the-laws).

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.

> **Note**
>
> 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.

### When a command takes effect

With most operators a command is enforced on the next control cycle. Some specifications instead give an instruction a **validity delay**, so that the operator and the installation agree on which instruction applies at a given moment: the instruction only becomes valid a fixed time after it was received, and compliance is judged against the instruction that was valid then. The EMS follows the operator's own rule, so a limit that seems slow to lift may simply be inside its delay. The operator's page states whether a delay applies and how long it is.

### 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 **measurements** of actual active and reactive power, grouped per **asset category** (solar, storage, EV, …) or per the operator's own grouping. How often depends on the link: the EMS pushes them on a fixed interval to an operator that expects to be told, and serves them on request to an operator that polls.

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

### Loss of the link

What must happen when the operator's RTU falls silent is part of the operator's specification, not a choice the EMS makes freely. Two rules hold everywhere:

-   **A standing instruction is held.** An order stands until it is countermanded, so the EMS never ramps back up on its own against an active curtailment.
-   **Losing the link is reported.** The controller raises an issue, so a silent link is visible on the platform rather than looking like normal operation.

Some operators supervise the link explicitly with a **watchdog** in each direction, held active while all is well so that losing the signal is itself the alarm. Where that applies, the operator's page describes what the installation falls back to while the alarm stands.

### 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 [Emergency stop](https://voltmasters.io/en/docs/dso-rtu/io-module/emergency-stop/)).