Beispiel: temporäre Kapazitätserhöhung im Trafobereich

Dieses Beispiel zeigt, dass Edge-EMS Builder keine fest eingebaute Geschäftslogik zur „Kapazitätserhöhung“ enthält. Die Strategie entsteht durch Kombination der drei Grundfunktionen Erfassung, Aggregationsausdrücke und Triggerschemata. Dasselbe Vorgehen lässt sich auf andere Szenarien mit „Schwellenwert überwachen → Reserve berechnen → Aktion ausführen“ übertragen.

1. Fachlicher Hintergrund

Ein Verteiltransformator versorgt einen Bereich mit fester Kapazität, beispielsweise 315 kVA oder 400 kVA. Kurzzeitige Lastkonzentrationen wie gleichzeitiges Schnellladen mehrerer Fahrzeuge oder saisonale Spitzen können die gemessene Last an die Nennkapazität heranführen oder darüber hinaus erhöhen. Eine klassische Transformatorerweiterung über den Netzbetreiber ist zeitaufwendig und teuer, obwohl häufig nur kurze Lastspitzen abgefangen werden müssen.

Die temporäre Kapazitätserhöhung im Trafobereich setzt einen Energiespeicher vor Ort ein. Edge-EMS Builder überwacht die Last in Echtzeit und fordert vor Erreichen der Transformatorgrenze automatisch eine Speicherentladung an. Die Speicherleistung deckt einen Teil des Versorgungsdefizits, sodass der gesamte Netzbezug innerhalb sicherer Grenzen bleibt. Sinkt die Last, endet der Unterstützungsmodus automatisch und der Speicher kehrt zur normalen Betriebsplanung zurück, etwa zum Laden in Schwachlastzeiten. Ohne Transformatorumbau entsteht so durch Softwarestrategie und Speicher eine vorübergehende Kapazitätserhöhung.

2. Beteiligte Geräte und Daten

Rolle	Gerät	Wichtige Datenpunkte
Hauptzähler des Trafobereichs	Intelligenter Zähler am Transformatorabgang	Gesamte Netzbezugsleistung Feeder_active_power (kW)
Speichersystem	PCS + BMS	Aktuelle Leistung PCS1_active_power (kW, positiv bei Entladung), SOC PCS1_soc (%), maximale verfügbare Entladeleistung PCS1_max_discharge_power (kW)
Strategieparameter	Benutzerdefinierte/Aggregationsdatenpunkte	Transformatornennkapazität Transformer_rated_capacity (kW), relativer Auslöseschwellenwert und SOC-Schutzuntergrenze

Diese Datenpunkte stammen aus den Rohdaten des Datenmodells – Messwerte von Zähler, PCS und BMS – sowie aus zeitabhängigen/benutzerdefinierten Daten für Schwellenparameter. Letztere können Betriebsteams saisonal anpassen, ohne Skripte zu ändern.

3. Aggregationsberechnung: verbleibende Kapazität und Unterstützungsbedarf

Erstellen Sie den Aggregationsdatenpunkt Feeder_headroom_kw für die verbleibende Kapazität mit folgendem Ausdruck:

-- Verbleibende Kapazität = Nennkapazität × Auslöseschwellenverhältnis - gemessene Netzbezugsleistung
local rated = tonumber(${Transformer_rated_capacity} or 0)
local ratio = tonumber(${Capacity_trigger_ratio} or 0.9)  -- Standard-Auslöseschwelle: 90 % der Nennkapazität
local used = tonumber(${Feeder_active_power} or 0)

return rated * ratio - used

Ein negativer Wert von Feeder_headroom_kw bedeutet, dass die Last die Auslöseschwelle erreicht oder überschritten hat und der Speicher einen Teil der Last übernehmen soll.

4. Triggerschema: automatische Entladung nahe der Lastgrenze

Auslösebedingung (Datenänderung, DATA_CHANGE):

return tonumber(${Feeder_headroom_kw} or 0) < 0

Triggeraktion:

local resultList = {}

local headroom = tonumber(${Feeder_headroom_kw} or 0)   -- Negativer Wert bezeichnet die fehlende Leistung
local soc = tonumber(${PCS1_soc} or 0)
local maxDischarge = tonumber(${PCS1_max_discharge_power} or 0)

-- SOC-Schutz: Unterhalb der Untergrenze nur warnen und keine Kapazitätserhöhung durchführen, um Tiefentladung zu vermeiden
if soc < tonumber(${SOC_protect_min} or 20) then
    table.insert(resultList, buildCommonAlarmMap(
        "增容能力不足", "台区负荷超限但储能SOC过低（" .. soc .. "%），无法执行临时增容，请人工介入"
    ))
    return resultList
end

-- Auszugleichende Leistung = Absolutbetrag des Defizits, begrenzt durch die maximale Entladeleistung des Speichers
local needPower = math.min(-headroom, maxDischarge)

table.insert(resultList, buildCommonWriteMap("Collection", "PCS1_power_setpoint", needPower, nil, nil, true))
table.insert(resultList, buildCommonAlarmMap("台区临时增容已启动", "台区负荷超限，储能按 " .. needPower .. " kW 放电分担负荷"))
table.insert(resultList, buildMqttAlarmMap("台区临时增容已启动", "储能放电分担台区负荷", 1, "alarm/upload", 1))

return resultList

5. Ausstiegsbedingung: Hysterese gegen häufiges Schalten

Wird „verbleibende Kapazität ≥ 0“ unmittelbar als Ausstiegsbedingung verwendet, können Lastschwankungen um den Grenzwert ein ständiges Ein- und Ausschalten des Speichers verursachen. Eine Hysterese verhindert dieses Pendeln: Einschalt- und Ausschaltschwelle erhalten unterschiedliche Werte.

Erstellen Sie den Aggregationsdatenpunkt Feeder_headroom_exit_kw für die Ausstiegsreserve mit einem größeren Abstand zum Grenzwert, beispielsweise dem Faktor 0.8 statt 0.9:

local rated = tonumber(${Transformer_rated_capacity} or 0)
local exitRatio = tonumber(${Capacity_exit_ratio} or 0.8)
local used = tonumber(${Feeder_active_power} or 0)

return rated * exitRatio - used

Erstellen Sie ein weiteres Triggerschema mit den Bedingungen ${Feeder_headroom_exit_kw} >= 0 und ${PCS1_power_setpoint} > 0 (Unterstützungsmodus aktiv). Als Aktion wird PCS1_power_setpoint schrittweise auf null zurückgeführt. Anschließend endet der Unterstützungsmodus und die normale Betriebsstrategie, etwa Laden in Schwachlastzeiten, wird fortgesetzt.

6. Kombination mit weiteren Funktionen

• Mehrere Speicher koordinieren: Über Gerätekoordination können die verfügbaren Kapazitäten mehrerer Speicher zu einem Aggregationsdatenpunkt zusammengeführt werden. Triggeraktionen verteilen die Entladung nach SOC oder proportional zur Nennleistung. Das Prinzip entspricht der Verteilung im Lastmanagementbeispiel für Ladestationen.
• Cloudvisualisierung und Betriebsplanung: Über Cloud-Edge-Koordination werden Feeder_headroom_kw, Aktivierungsstatus und Speicherleistung regelmäßig an die Cloud gemeldet. Betriebsteams können mehrere Trafobereiche fernüberwachen. Die Cloud kann zudem Parameter wie Auslöseschwellen zur dynamischen Strategieanpassung senden.
• Wiederverwendung in großem Maßstab: Bei vielen gleich aufgebauten Trafobereichen mit identischen PCS-/BMS-Modellen und ähnlicher Strategie können UDE-Vorlagen die Aggregationsdatenpunkte definieren. Neue Bereiche erhalten automatisch ihre Konfiguration, ohne jeden Bereich erneut manuell aufzubauen.

7. Zusammenfassung

Alle hier verwendeten Funktionen – Rohdatenerfassung, Reserveberechnung durch Aggregationsausdrücke, datenabhängige Auslösung, Befehle über Schreibaktionen sowie Alarme und MQTT-Meldungen – sind allgemeine Bausteine von Edge-EMS Builder. Die konkrete Logik zur temporären Kapazitätserhöhung entsteht vollständig durch deren Konfiguration. Werden Zähler und PCS durch andere Geräte und die Schwellenprüfung durch andere Geschäftsregeln ersetzt, lässt sich derselbe Ansatz auf Lastspitzenkappung, Lastverlagerung, Leistungsbegrenzung, die Kombination mehrerer Energiequellen und nahezu alle Szenarien mit „Überwachen → Entscheiden → Ausführen“ übertragen.

Diese Abbildung basiert auf der Konfigurationslogik dieser Seite und zeigt Daten- und Steuerungsabläufe. Konkrete Felder entnehmen Sie den beschriebenen Konfigurationen und Skripten.

⚠️ Schwellenverhältnisse, SOC-Schutzuntergrenzen und andere Parameter sind nur Beispiele. In tatsächlichen Projekten müssen sie anhand der Transformatornennkapazität, verfügbaren Speicherkapazität und lokalen Vorgaben zur Betriebsführung festgelegt werden.