> 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/grid-operators/sibelga.md). # Sibelga DSO RTU with Sibelga, the Brussels-Capital Region grid operator, over a Modbus producer link with a setpoint per production type. 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](/dso-rtu/rtu-connection.md) 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. {% hint style="info" %} 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. {% endhint %} ### 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**](/dso-rtu/io-module.md). 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. {% hint style="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. {% endhint %} ### 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](/dso-rtu/how-dso-rtu-works.md) for the general control model. * [RTU connection](/dso-rtu/rtu-connection.md) for the on-site connection and network requirements. * [IO module](/dso-rtu/io-module.md) for the module that carries the breaker feedback inputs. * [Commissioning & certification](/dso-rtu/commissioning-and-certification.md) for the validation process. --- # 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, and the optional `goal` query parameter: ``` GET https://docs.voltmasters.io/dso-rtu/grid-operators/sibelga.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.