# Sibelga

> DSO RTU with Sibelga, the Brussels-Capital Region grid operator, over a Modbus producer link with a setpoint per production type.

Source: https://voltmasters.io/en/docs/dso-rtu/grid-operators/sibelga/

Sibelga is the distribution grid operator for the Brussels-Capital Region. The Voltmasters EMS supports DSO RTU with Sibelga, following the Sibelga specification **SIB24 CCLB 111**, with the register map from its Bijlage 2 and the instruction set from **SIB25 CCLB E097**.

To use it, set the DSO RTU provider to **Sibelga** under **Configuration → Grid & market → DSO RTU settings**.

### Connection

Sibelga's RTU is the Modbus **master** and the customer's equipment is the slave. The EMS plays that slave, the role the specification calls the **Centraal PLC**: it serves registers and answers the RTU's polls, and never initiates traffic of its own.

| Parameter | Value |
| --- | --- |
| Protocol | Modbus, the EMS as slave |
| Slave address | 10 |

The specification describes the link as Modbus RTU over RS-485. In our deployment the controller serves Modbus TCP and the link is bridged to RS-485 by a gateway, which must be configured as an RTU master on the serial side and a Modbus TCP client toward the EMS.

See [RTU connection](https://voltmasters.io/en/docs/dso-rtu/rtu-connection/) for the on-site connection and network requirements.

### The register map

Sibelga organises the installation by **production type**, each with its own block of registers in an identical layout:

| Block | Base register | Served |
| --- | --- | --- |
| PV | 100 | Yes |
| CHP | 200 | Published as out of service |
| Storage | 300 | Yes |

The EMS controls no CHP, so that block is published as out of service with open breakers rather than left unanswered.

#### What the EMS reports (Sibelga reads)

| Point | Source |
| --- | --- |
| Active power | The production of that type. Storage is reported as discharge power; the register cannot carry the charging direction. |
| Reactive power | The reactive power of the devices of that type. |
| Cos φ | The power factor derived from the two above. |
| Production status | Whether that production type is in service. |
| Decoupling breaker position | Read from a breaker feedback input, see below. |
| Back-up breaker position | Read from a breaker feedback input, see below. |

#### What Sibelga instructs (Sibelga writes)

| Point | Meaning |
| --- | --- |
| Active power setpoint | A cap on that production type, as a **percentage of its maximum production**. **100 % means no regulation demand.** |
| Cos φ setpoint | A power factor the installation must hold for that production type. |

The EMS applies the setpoint to the matching assets: the PV block steers the PV inverters, the storage block steers the batteries. An instruction outside its valid range is **ignored**, never applied, and raises an incident; the EMS still echoes it back as received so Sibelga can see what arrived.

> **Note**
>
> Sibelga steers **per production type only**. There is no instruction on the grid connection point and none on the assets as a whole, so a limit always applies to the PV or to the storage, never to the site as a whole.

### Reactive power

Sibelga instructs reactive power as a **cos φ target** per production type. The EMS applies it as its power-factor control law and distributes the required reactive power across the capable devices of that type. When neither block carries a target, reactive control stays on its local behaviour.

### Breaker positions

The two breaker positions the EMS reports are read from **digital inputs on an [IO module](https://voltmasters.io/en/docs/dso-rtu/io-module/)**. This is feedback flowing **out** of the installation toward Sibelga; it is not how Sibelga sends instructions.

Configure them under **Switch positions** in the DSO RTU settings. Each entry maps one input port to:

-   a **production type**: PV or battery, so the position lands in the right register block, and
-   a **switch type**: the **decoupling** breaker or the **back-up** breaker.

Leaving the list empty reports every breaker as in service.

> **Warning**
>
> The **decoupling breaker is the autonomous C10/21 protection relay**. The EMS never drives it: it only reports the position of that relay as telemetry. Safety decoupling happens without the EMS and does not depend on it.

### No emergency stop, no reason codes

The Sibelga protocol carries **no emergency-stop command** in either direction (SIB24 CCLB 111 §7.13.5), so there is no relay for the EMS to assert and no DSO RTU emergency stop to configure on this provider. Grid-fault decoupling is the C10/21 relay described above.

The instructions also arrive **without a reason code**: an active-power or cos φ setpoint states no cause.

### Incidents

| Incident | Severity | Meaning |
| --- | --- | --- |
| Sibelga Modbus server is not listening | Critical | The slave is not serving, so Sibelga cannot reach the installation. |
| Reactive power unavailable (PV or storage) | Warning | A device of that type does not report reactive power. The missing value counts as zero, so the reported reactive power understates reality and the reported cos φ is biased toward unity. |
| Invalid cos φ setpoint | Warning | A received cos φ instruction lies outside its valid range and is therefore ignored. |

### Next steps

-   [How DSO RTU works](https://voltmasters.io/en/docs/dso-rtu/how-dso-rtu-works/) for the general control model.
-   [RTU connection](https://voltmasters.io/en/docs/dso-rtu/rtu-connection/) for the on-site connection and network requirements.
-   [IO module](https://voltmasters.io/en/docs/dso-rtu/io-module/) for the module that carries the breaker feedback inputs.
-   [Commissioning & certification](https://voltmasters.io/en/docs/dso-rtu/commissioning-and-certification/) for the validation process.