> 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/fluvius/fall-back-flex.md). # Fall-Back Flex How the Voltmasters EMS supports Fluvius Fall-Back Flex connections: what the formula means, how an activation is executed, how the day-ahead planning API is handled, and how you configure and monitor **Fall-Back Flex** is a temporary connection formula from Fluvius for new or reinforced connections (from 100 kVA) in areas with grid congestion. The customer connects at the **full requested capacity**; in return, the installation must temporarily reduce its net offtake to a **setpoint** whenever Fluvius signals local congestion. The formula lapses once the planned grid investment in the zone is completed, or it is converted into a flexible connection agreement. Fall-Back Flex is not a separate connection to the EMS: it runs **on top of the Fluvius Netflex DSO RTU connection**. Fluvius sends the setpoint through the same RTU and the same IEC 60870-5-104 interface described in [Fluvius](/dso-rtu/grid-operators/fluvius.md). Zones that require it also publish a **day-ahead plan** through the Fluvius planning API, which the EMS consumes as well. {% hint style="info" %} Whether a connection qualifies for Fall-Back Flex, and whether day-ahead steering is mandatory, is stated in the Fluvius zone sheet of the congestion area. The commercial parameters (P\_base and the reduced power P\_red) come from the bid form agreed with Fluvius. {% endhint %} ### The two power levels | Level | Meaning | | ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **P\_base** | The contractual import access power of the grid connection, as stated on the bid form (including capacity still under request). It is the 100 % reference of every Fluvius percentage, also when the project's own grid settings (a desired monthly peak, a safety margin) keep the installation below it. | | **P\_red** | The reduced power from the awarded bid: the lowest setpoint Fluvius can send, so the maximum net offtake during an activation. | Everything between P\_red and P\_base is the **flexible volume** (V = P\_base − P\_red): the share of the connection the installation must be able to give up when Fluvius activates. The Fluvius setpoint arrives as a **percentage of P\_base** (`MAXSETP`). A setpoint of 100 % means no restriction; a setpoint of 70 % on a 1 MW connection means the net offtake at the connection point may not exceed 700 kW. The setpoint is always an upper bound, never a request to consume a fixed amount. ### How an activation is executed Fluvius sends the setpoint through the Netflex RTU with reason code `1` (congestion) or `99` (reduction test), and the EMS mirrors every setpoint straight back to Fluvius. From that moment the installation has **3 minutes** to be at or below the setpoint, and it has to stay there for as long as the setpoint applies. Activations are possible 24/7, and because the controller runs locally and the RTU link does not depend on an internet connection, an activation is executed correctly during connectivity problems as well. If the RTU link itself drops, the EMS keeps applying the last setpoint it received: a setpoint never expires on its own, it is only replaced by the next one. The EMS works on two time scales: it **plans ahead** with the day-ahead plan where Fluvius publishes one, and it **regulates live** on the grid measurement while a setpoint is active. The live loop is always present, whether or not a plan announced the restriction. #### Ahead of time: planning with the day-ahead plan In zones with day-ahead steering the EMS knows the restricted quarter hours a day in advance. It uses that knowledge so that the flexible volume is delivered with as little disruption as possible: * **Battery schedule.** Every planned quarter hour with an import limit below 100 % is handed to the battery schedule as a *cover deficit* slot. The schedule then plans the battery around it: it charges (from PV surplus or, when the prices allow, from the grid) in the hours before the restriction and reserves that energy, and during the restricted quarter hours the battery discharges to cover the site's consumption so the net offtake stays below the planned limit. A manual strategy override on the same quarter hour does not cancel a planned restriction: the planned restriction wins. A trading signal can still steer the battery within the schedule, but the planned limit itself keeps applying as a maximum on the net offtake. * **Limits before the live setpoint arrives.** The planned limit is applied as a maximum net offtake from the start of the quarter hour, even if the live Netflex setpoint has not been sent yet or is looser. When both are present the stricter one applies. * **Loads are not switched in advance.** Controllable loads are only shed when the live measurement requires it, because switching them earlier would remove comfort or production without a gain: the battery and the limit itself already keep the quarter hour within bounds. Load shedding is the fall-back when the battery cannot carry the restriction alone. Without a day-ahead plan (zones with pure live steering) there is nothing to plan: the battery follows its normal strategy until a setpoint arrives, and the live loop below does all the work. #### At the moment itself: live regulation As soon as a setpoint below 100 % is active, the EMS runs a closed loop on the net offtake at the connection point, once per second: 1. **Target.** The target is the setpoint minus a safety margin (a small percentage of P\_base with a minimum in kW), so that meter noise and short peaks do not push the quarter-hour average over the setpoint. 2. **Excess.** The excess is what the installation is *about to draw* above the target: the current grid measurement, corrected for what has already been asked of the flexible devices but is not yet visible in the meter. Only the excess is removed; the rest of the site is not touched. 3. **Priority groups.** The excess is covered by the [priority groups](#load-shedding-priorities), group 1 first, and within a group the modulating devices (battery, EV chargers) go before the switched loads. What each type gives up is listed [below](#what-each-device-type-does). Two rules matter here: the battery's charging is stopped before it is asked to discharge, because charging during an activation only adds to the net offtake, and the setpoint takes precedence over the battery's normal strategy for as long as it applies, so a scheduled charge, a trading signal or self-supply logic cannot make the battery import during an activation. 4. **Verify on the meter, not on the request.** After each step the EMS waits a short settle window (the meter latency plus a couple of seconds) and looks at the grid measurement again. Switching a load off is no guarantee that it was really drawing its nominal power, and a battery may not deliver what was asked. Whatever shortfall remains in the measurement is covered by the next device or the next group; a device that does not follow its cap for 30 seconds is skipped so it cannot block the escalation. The whole ramp-down has to be complete within the 3-minute response time. 5. **Hold.** Once the measurement is at or below the target the EMS stops escalating and holds the caps. It keeps watching: when consumption grows during the activation (a machine starts, a cold store kicks in) the loop escalates further; when it drops, capacity is released again. 6. **Release.** When Fluvius relaxes or ends the setpoint, or when there is room below the target, the EMS gives consumption back **gradually**: in power steps of 10 % of P\_base per minute, the last-shed device first. Loads stay off for at least 10 minutes and paused EV connectors for at least 2 minutes, so nothing cycles on and off. The battery is released last: its charging only resumes once the loads and chargers are back and the measurement still has room. {% hint style="info" %} The live loop only ever **lowers** net offtake. It never asks the battery to export or a load to switch on to reach a value: the setpoint is an upper bound, and staying below it is always compliant. {% endhint %} The project's standard grid protection remains active underneath: the fuse protection on the energy meter and the oscillation prevention run after Fall-Back Flex, so an activation can never lead to an overload or a flapping device. #### What each device type does | Device type | How it is shed | | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Battery** | Charging is blocked first; when more is needed the battery discharges to cover consumption, up to its rated power and down to the energy floor the EMS keeps above the minimum state of charge (a battery at its minimum SoC counts as no flexibility). Its flexibility is therefore up to twice its rated power. On a connection that also has technical flex, a battery in the registered asset group is only used as far as the asset setpoint (`MINSETAP`) still allows production: taking power off it counts as production of the asset group, a blocked charge just as much as a discharge. | | **EV chargers** | Connector setpoints are lowered by exactly the shortfall, lowest connector priority first. A connector that would fall below the minimum charging current is paused instead, and stays paused for at least 2 minutes. | | **Controllable loads** | Switched off as a whole through the IO module. The EMS picks the load whose nominal power best fits the remaining shortfall, so as few loads as possible are switched. A shed load stays off for at least 10 minutes, so compressors and boilers do not cycle. | A connection with both steerings can therefore run into two obligations at once: the setpoint at the connection point asks for less consumption, while the asset setpoint caps what the asset group may produce. The EMS respects both and meets the setpoint from the other devices instead. If those fall short, it reports that it ran out of flexibility rather than breaking one of the two orders, which is the moment to bring the shortfall to Fluvius. #### Emergency stop The Netflex **emergency stop consumption** command is honoured independently of the setpoint: every flexible consumer in the priority list (battery charging, EV charging, loads) is switched off at once. The battery is not forced to discharge on an emergency stop. ### Step-by-step guide for installers Fall-Back Flex sits on top of a working Netflex connection, so the base configuration comes first: provider, emergency stops, measurement channels, asset group and access powers, as [Configuring Fluvius telecontrole](/dso-rtu/grid-operators/fluvius/configuration.md) walks through them. The steps below are what Fall-Back Flex adds on top, in the order to do them. {% stepper %} {% step %} #### Collect the contract data From the Fluvius bid form and zone sheet you need: **P\_base** (contractual import access power, in kW), **P\_red** (reduced power, in kW), the **asset point id** of the connection, and whether **day-ahead steering** is mandatory for the zone. For a day-ahead zone you also need the **program ids** Fluvius publishes for the connection and, per program, which reference power its percentages apply to. {% endstep %} {% step %} #### Order the planning certificate and register it with Fluvius Only for day-ahead zones, and worth starting first because it has the longest lead time. The customer orders an **OV client certificate** (2048 bit, at most one year) with a recognised certificate authority; generate the key pair yourself and keep the private key. Once the certificate is issued, **send the public certificate to Fluvius** at , together with the asset point id it must be bound to, and ask in the same mail which program ids the connection will receive. Never send the private key. Fluvius couples the certificate server-side to that asset point, and only that coupling makes the planning API answer: until it exists, a technically perfect certificate is refused with `UNAUTHORIZED_CERTIFICATE`. Wait for the confirmation from Fluvius before you rely on the day-ahead steering. [Planning certificate](/dso-rtu/grid-operators/fluvius/fall-back-flex/planning-certificate.md) walks through the whole order, the file formats and the renewal. {% endstep %} {% step %} #### Check the grid settings Under **Configuration → Grid & market → Grid settings**, make sure the **import access power** equals P\_base from the bid form. This value is the 100 % reference of `MAXSETP`, so a wrong P\_base shifts every activation. Leave it empty and Fall-Back Flex steers nothing at all: without a 100 % reference no percentage can be turned into kW, so the EMS reports the gap as an incident instead of guessing. {% endstep %} {% step %} #### Finish the base Netflex configuration Provider, emergency stops, measurement channels and the asset group, per [Configuring Fluvius telecontrole](/dso-rtu/grid-operators/fluvius/configuration.md). Verify on the [DSO RTU dashboard](/voltmasters-platform/dashboards/dso-rtu-dashboard.md) that the link is up and every setpoint reads 100 % before you switch Fall-Back Flex on. {% endstep %} {% step %} #### Enable Fall-Back Flex In the same form, enable **Fall-Back Flex active** and enter **P\_red**. For day-ahead zones, enable **Day-ahead steering**, fill in the asset point id, list the **day-ahead programs** Fluvius announced for the connection with their reference power, and upload the client certificate and private key that Fluvius registered. Save; the controller picks the new configuration up within a minute. {% endstep %} {% step %} #### Make the flexible consumption controllable Every device you want to shed must be controllable by the EMS: batteries and EV chargers through their own integration, other loads (boilers, heat pumps, cooling, process loads) as **controllable loads** switched through an [IO module](/dso-rtu/io-module.md) relay. Add them under **Configuration → Devices** with their **nominal power**. Without controllable devices the EMS cannot honour an activation. {% endstep %} {% step %} #### Register the flexible consumption In the DSO RTU settings, fill in the **registered flexible consumption power** from the zone sheet and check that channel 6 holds everything that power covers, the battery included. The coverage check under [Netflex measurement channels](https://docs.voltmasters.io/dso-rtu/grid-operators/fluvius/pages/SfjNq8956AsYc7n2AqFg#5.-netflex-measurement-channels) has to be green: what Fluvius sees drop during an activation is that channel. See [what Fluvius watches](#what-fluvius-watches-during-an-activation). {% endstep %} {% step %} #### Set the load shedding priorities Under **Configuration → Strategy → Load shedding priorities**, drag the devices into priority groups (see [below](#load-shedding-priorities)). Check the coverage line: the controllable power in the groups must be at least the flexible volume **P\_base − P\_red**. Devices that may never be shed go under **Not in the list**. {% endstep %} {% step %} #### Test before commissioning with Fluvius Ask Voltmasters support to force a test setpoint on the controller (for example 80 %) and watch the **Fall-Back Flex** page: the net offtake must drop below the setpoint within 3 minutes and the shedding execution must show which devices were used. Also test the **emergency stop consumption**. Then plan the commissioning test with Fluvius (reason code 99); Voltmasters assists remotely, see [Commissioning & certification](/dso-rtu/commissioning-and-certification.md). {% endstep %} {% step %} #### Keep it running Watch the incidents **Fall-Back Flex setpoint not reached** and **flexibility exhausted**; they mean the priority list needs more devices. Report any change of the installation (added or removed assets, higher peak power) to Fluvius: it triggers a new reduction test. Renew the planning certificate before it expires: the platform starts mailing 60 days ahead and the controller warns 30 days ahead, see [Planning certificate](/dso-rtu/grid-operators/fluvius/fall-back-flex/planning-certificate.md#renewal). {% endstep %} {% endstepper %} ### Configuring Fall-Back Flex Fall-Back Flex lives inside the DSO RTU configuration, under **Configuration → Grid & market → DSO RTU settings**, with **Fluvius Netflex** as provider. The fields, in the order they appear in the form: | Field | What to enter | | ------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Technical flex imposed** | Off for a connection with only Fall-Back Flex. On when the study also imposes technical flex, which puts the asset channels in scope (see [measurement channels](#what-fluvius-watches-during-an-activation)). | | **Registered flexible consumption power** | The flexible consumption power the zone sheet registers for channel 6, in kVA. Ask the customer for the zone sheet: this figure is not in the study document. | | **Fall-Back Flex active** | On for a connection with the Fall-Back Flex formula. | | **P\_base (contracted power)** | Read-only: the import access power from the [grid settings](/voltmasters-platform/10.-project-settings/10.5-project-settings.md#grid-settings) of the project. | | **P\_red (offered power limit)** | The reduced power from the awarded bid. The form draws the resulting flexible volume V = P\_base − P\_red, so you can check both against the bid form. | | **Day-ahead steering through the Fluvius planning API** | On when the zone sheet states "Day Ahead steering: yes". The fields below only appear then. | | **Asset point id** | The asset point id Fluvius assigned to the connection, from the bid form or zone sheet. | | **Planning API base URL** | Leave empty; only fill it in when Fluvius hands you a URL that differs from its production one. | | **Day-ahead programs** | Every program id Fluvius announced for the connection, each with the reference power its percentages apply to (see [One program per steering](#one-program-per-steering)). | | **Client certificate**, **Private key**, **CA chain** | The OV certificate and its private key as registered with Fluvius ([how to obtain them](/dso-rtu/grid-operators/fluvius/fall-back-flex/planning-certificate.md)); the Fluvius CA chain is optional. |
Voltmasters EMS: Fall-Back Flex section in the Fluvius DSO RTU settings, with P_base, P_red, the day-ahead planning toggle, the day-ahead programs and the certificate uploads

Fall-Back Flex in the Fluvius DSO RTU settings: P_base comes from the grid settings, P_red from the bid; day-ahead steering adds the asset point id, the day-ahead programs and the client certificate.

#### Certificate for the planning API Fluvius authenticates the planning API exclusively with a client certificate (mutual TLS); there are no API keys or passwords. Fluvius requires: * an **OV certificate** (organisation validated) from a recognised certificate authority; self-signed certificates are refused; * a key of at least **2048 bits**; * a validity of at most **one year**; a replacement certificate must be announced to Fluvius **90 to 15 days before expiry**. The certificate is ordered by the customer with a commercial certificate authority, and the **public certificate has to be sent to Fluvius** () with the asset point id before the API accepts it. [Planning certificate](/dso-rtu/grid-operators/fluvius/fall-back-flex/planning-certificate.md) covers the whole cycle: what to prepare, where to buy one, how to generate the key and the CSR, how to register the certificate with Fluvius, which file formats the platform accepts and how to renew without a gap. The platform validates the upload (readable certificate, matching private key, not expired) and shows only the thumbprint and the expiry date afterwards. From 60 days before the expiry date the platform mails the project members who receive notifications, and the EMS raises an incident 30 days before the certificate expires. ### What Fluvius watches during an activation Fluvius settles compliance on the billing meter at the connection point, but the Netflex cabinet also watches the **flexible consumption channel** (channel 6): during a setpoint that is where the operator expects to see the power drop. What ends up in that channel therefore has to match the dossier, and on a Fall-Back Flex connection that is not simply "the loads": * Everything the zone sheet counts as flexible consumption belongs in **channel 6**, the battery included. A battery below 250 kVA is not subject to technical flex, so it does not belong in the storage channel; on these connections it is part of the flexible consumption power instead. * **EV charging stays separate in channel 5**, also when the chargers are part of the flexible consumption power. * Without technical flex, the asset channels (1, 2, 3, 4 and 7) stay empty, even for PV or a battery the EMS measures itself. The channel per device is configured in the same DSO RTU settings form, in the **Netflex measurement channels** section, which also compares the configured flexible consumption against the power registered in the zone sheet. [Measurement channels](/dso-rtu/grid-operators/fluvius.md#measurement-channels) explains the mapping and shows the form.
Voltmasters EMS: the flex scope of the dossier, with the technical flex switch and the registered flexible consumption power in kVA

The flex scope of the dossier decides which channels Fluvius expects; the registered flexible consumption power is the reference for channel 6.

{% hint style="warning" %} A flexible consumption power that is configured well below the figure in the zone sheet is the classic mistake: the operator then sees only part of the registered volume drop during an activation and counts the service as not delivered, even though the installation did reduce. The check in the measurement channels section is there to catch exactly that. {% endhint %} ### Load shedding priorities Which devices are used during an activation, and in which order, is configured under **Configuration → Strategy → Load shedding priorities**. The same list is used by the project's standard grid limit protection, so the shedding behaviour is the same whatever the reason for the limit. Devices are dragged into **priority groups**: * **Group 1** is limited first. A later group is only used when the earlier groups cannot cover the required reduction. * **Within a group** the EMS decides the order itself: devices that can modulate (battery, EV chargers) go first because they take away exactly the power that is needed; switched loads follow, and the EMS picks the load that best fits the remaining shortfall (the largest load that fits, or the smallest one that covers it) so the overshoot and the number of relay switches stay small. On a tie, the load with the most slack (later runtime deadline, shorter minimum runtime) is shed first. * Devices under **Not in the list** are never shed, whatever happens. * Each card shows the device's **controllable power** and whether it is **modulated** or **switched**. The coverage line compares the total controllable power in the groups with the required reduction (P\_base − P\_red), so you can see whether the list can always honour an activation. Without a saved order the EMS uses its default: batteries first, then EV chargers, then the loads.
Voltmasters EMS: load shedding priority groups with drag-and-drop, a Not in the list zone and a coverage check against the required reduction

Load shedding priorities: devices are dragged into priority groups; the coverage line checks the total controllable power against the flexible volume.

{% hint style="info" %} Add every load you are willing to shed to a group, including the ones you would only use as a last resort. A list that cannot cover the flexible volume means an activation may not be fully honoured, which Fluvius counts as a non-delivered service for that quarter hour. {% endhint %} ### Day-ahead planning For zones with mandatory day-ahead steering, Fluvius also publishes the expected limits **one day ahead** (and up to six days ahead) as quarter-hour intervals through its planning API (an OpenADR 3.1 profile). The EMS: * polls the plan every minute and acknowledges every new version to Fluvius. One read receipt per version is enough: Fluvius dropped both the second acknowledgement and the quarter-hour compliance report its specification originally asked for; * applies the **stricter** of the planned limit and the live Netflex setpoint at all times. With an accurate plan the cabinet stays at 100 % and the plan is the only limit; when congestion occurs anyway the cabinet dives below the plan, and then the cabinet is what the installation follows; * keeps the last confirmed plan locally, so a temporary loss of connectivity does not change what the installation does; * uses the plan to **prepare**: quarter hours with a planned restriction are handed to the battery schedule, so the battery is charged before the restriction and discharges during it, instead of only shedding once the limit bites. A quarter hour without a restriction is published at 100 % (or -100 % on the production side), and that is also how Fluvius withdraws an instruction it published earlier. #### One program per steering Fluvius publishes a **program** per steering product on the same API, and the percentages of a program refer to the same reference power its cabinet setpoints do: | Program | Cabinet setpoints | The percentages are a share of | | -------------------- | ----------------------- | ----------------------------------------------- | | **Fall-Back Flex** | `MAXSETP` / `MINSETP` | the contractual capacity of the grid connection | | **T-Flex day-ahead** | `MAXSETAP` / `MINSETAP` | the registered reference power of the assets | A connection that takes part in both steerings receives both programs, and Fluvius links program, customer and installation itself: everything the API returns for the connection's certificate applies to that connection. The payload does not say which reference power a program uses, so the program ids Fluvius announces for the connection are listed under **Day-ahead programs** in the DSO RTU settings, each with its reference power. A program that arrives without being listed is read as a connection-point limit and raises a **Day-ahead program without a reference power** incident, so the mapping can be completed before it steers against the wrong base. When two programs restrict the same quarter hour, the lowest limit per reference power applies.
Voltmasters EMS: the day-ahead program list in the Fall-Back Flex settings, mapping each Fluvius program id onto its reference power

Day-ahead programs: every program id Fluvius announces is mapped onto the reference power its percentages apply to.

### Monitoring Projects with Fall-Back Flex enabled get a **Fall-Back Flex** page in the project menu. The **Demo: show sample data** switch at the top of that page fills every block with an example activation, which is the easiest way to see what to expect before the first real one (the figures below use it). The page shows: * **Status banner**: whether an activation is running, since when, and warnings when the response deadline was missed or the priority list ran out of flexibility. * **Grid connection bar**: the contracted power, the currently enforced limit and the actual net offtake in one view, including the share of the connection that is temporarily unavailable. * **Net consumption and setpoint (today)**: net offtake versus the enforced limit over the day, showing the ramp-down at the start of an activation. * **Load shedding order execution**: per device, in priority order, how much power was removed and its state (limited, shed, blocked, standby, or untouched for a device outside the priority list). * **Activation history**: past activations with duration, lowest setpoint, reason (congestion or reduction test), the number of quarter hours the installation stayed below the setpoint, and the result.
Voltmasters EMS: Fall-Back Flex page with status banner, grid connection bar, power chart and shedding execution

The Fall-Back Flex page during an activation (sample data): status banner, grid connection bar and net offtake versus the enforced limit.

Voltmasters EMS: load shedding order execution and activation history on the Fall-Back Flex page

Below the chart (sample data): the shedding execution per device, in priority order and with the reduction per device, and the history of all activations with the number of compliant quarter hours.

The **EMS dashboard** also shows a Fall-Back Flex tile with the live status and a per-device icon row, so an ongoing activation is visible at a glance.
Voltmasters EMS: Fall-Back Flex tile on the EMS dashboard showing an active modulation and per-device icons

The Fall-Back Flex tile on the EMS dashboard: live status, the enforced setpoint and per-device icons.

#### Incidents The EMS raises incidents when an activation cannot be honoured: | Incident | Severity | Meaning | | ------------------------------------------------ | ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Fall-Back Flex setpoint not reached | Critical | The net offtake is still above the setpoint 3 minutes after the setpoint was tightened or exceeded. | | Fall-Back Flex flexibility exhausted | Warning | Every device in the priority list is shed and the offtake is still above the target. | | Fluvius planning API unreachable / report failed | Critical / Warning | The day-ahead plan could not be fetched, or the acknowledgement of a plan could not be delivered after its retries. | | A Fluvius planning event was rejected | Warning | A published plan could not be read (an unexpected structure or interval). That plan is not applied; the previous one keeps running. | | Day-ahead program without a reference power | Warning | Fluvius published a program that is not in the day-ahead program list, so its percentages are read against the connection point. Add the program with its reference power. | | Planning certificate expiring / expired | Warning / Critical | The client certificate for the planning API expires within 30 days, or has expired. | ### Frequently asked questions
Is Fall-Back Flex the same as DSO RTU (telecontrole)? No. DSO RTU is the generic control link with the grid operator. Fall-Back Flex is a specific connection formula that uses that link: Fluvius sends its congestion setpoints through the same Netflex RTU. A project can have Fluvius DSO RTU without Fall-Back Flex, but not the other way around.
Where do P_base and P_red come from? P\_base is the contractual import access power of the grid connection and is taken from the project's grid settings; it must match the P\_base on the Fluvius bid form. Without it Fall-Back Flex does not steer, because every Fluvius percentage needs that 100 % reference. P\_red is the reduced power the customer committed to in the bid form; it is entered once when enabling Fall-Back Flex.
What if the controllable power does not cover the required reduction? The load shedding priorities compare the total controllable power of the devices in the groups against the required reduction (P\_base minus P\_red) and warn when it falls short. Add more devices to the groups (for example loads switched through the IO module) or review which devices sit under Not in the list.
Does an activation switch everything off? No. The EMS removes only the power needed to reach the setpoint, group by group. Devices that can modulate are limited rather than switched off, and later groups are left untouched when the reduction is already covered.
Which day-ahead programs do we have to enter? The ones Fluvius announces for the connection: one program for Fall-Back Flex, and a second one when the connection also takes part in T-Flex day-ahead. Ask Fluvius for the program ids when you register the certificate. As long as a program is missing from the list its percentages are read against the connection point, which is right for Fall-Back Flex but wrong for an asset steering, so the EMS raises the **Day-ahead program without a reference power** incident with the program id it received.
How does Fluvius judge whether we complied? Fluvius evaluates per quarter hour, using the billing meter at the connection point: a quarter hour in which the net offtake stayed at or below the setpoint counts as delivered, a quarter hour above it counts as not delivered. After a setpoint change the installation has 3 minutes to comply. The activation history on the Fall-Back Flex page shows the same quarter-hour view.
How long does Fall-Back Flex apply? The formula is explicitly temporary: it lapses once Fluvius has completed the planned grid investment in the zone, or it is converted into a flexible connection agreement. The DSO RTU connection itself remains in use afterwards.
--- # 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/fluvius/fall-back-flex.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.