Anleitungen zur Präsentationsvorlage der Salzburg AG€¦ · › Function Model (SGAM Function Layer) › ArchitectureModel (SGAM Information, Communication und Component Layer)

INTEGRAIntegrierte Smart Grid Referenzarchitektur lokaler intelligenter Verteilnetzeund überregionaler virtueller Kraftwerke

Robert PriewasserScience Brunch "Smart Grids", 29.01.2018 in Linz

DATEN ZUM PROJEKT

Programm:Energie der Zukunft (Energy Mission Austria) Ausschreibung: e!MISSION 2012 1.AS (Koop. BMVIT/KLIEN. SG)

Projektnummer: 838793

Dauer des Projekts: 01.04.2013 - 31.03.2016

Projektbudget: € 2.039.923,--

Ansprechpartner: Robert Priewasser

Postadresse: Bayerhamerstr. 16, 5020 Salzburg

Telefon: 0662/8882-2238

E-Mail: [email protected]

INTEGRA@Science Brunch Seite 229. Jänner 2018

KONSORTIALPARTNER

› Salzburg AG, Bayerhamerstrasse 16, 5020 Salzburg

› AIT Austrian Institute of Technology GmbH, Donau City Straße 1/Tech Gate Vienna, 1220 Wien

› Technische Universität Wien, Institut für Energiesysteme und Elektrische Antriebe, Gusshausstraße 25-29/370-1, 1040 Wien

› Siemens Aktiengesellschaft Österreich, Siemensstraße 90, 1210 Wien

› OFFIS e.V., Escherweg 2, D-26121 Oldenburg


PROJEKTMITARBEITER

› Robert Priewasser, Salzburg AG› Konrad Diwold, Siemens AG Österreich› Tobias Gawron-Deutsch, Siemens AG Österreich› Friederich Kupzog, Austrian Institute of Technology GmbH› Christian Neureiter, Fachhochschule Salzburg› Wolfgang Prüggler, Technische Universität Wien – Energy Economics

Group› Sebastian Rohjans, OFFIS e.V.› Florian Schlögl, OFFIS e.V.› Roman Schwalbe, Austrian Institute of Technology GmbH› Franz Zeilinger, Siemens AG Österreich


INHALT

Ausgangssituation 06Problemstellung 07Ampelmodell 08SGAM M490 Modell 09Modellierungssprache 10

Referenzarchitektur 13Koordinierte Spannungsregelung 14Flexibility Operator 17Building Energy Agent 19Ökonomische Bewertung 20

29. Jänner 2018 INTEGRA@Science Brunch Seite 5

› Vorarbeiten in Projekten auf nationaler und internationaler Ebene stellen eine fundierte Grundlage für den Aufbau von Business Cases im Smart Grid dar

› Fragmentiertes Bild einer allgemein gültigen Smart Grid Architektur aus divergenten Anforderungen unterschiedlicher Regionen bzw. Kundenwünschen

› Im IKT-Bereich stehen unterschiedliche Protokolle und Schnittstellen teilweise in Konkurrenz zueinander und erlauben eine schlechte Systeminteroperabilität

AUSGANGSSITUATION


PROBLEMSTELLUNG

› Alle Marktteilnehmer sollen ihre Anforderungen und Interessen möglichst uneingeschränkt, jedoch unter Berücksichtigung relevanter Schnittstellen zu den Interessen der anderen Marktteilnehmer, wahrnehmen können

› Es wird untersucht, ob und wie zwischen den Netzebenen (Mittel- und Niederspannung) eine Verknüpfung der Regelalgorithmen erreicht werden kann

› Es soll analysiert werden, wie die Netzregelung organisatorisch (also über Marktregeln) und technisch an einen Flexibility Operator angebunden werden kann, um das notwendige Zusammenspiel Markt –Kunde – Netz in allen Betriebs- und Marktsituationen geeignet sicher zu stellen


› Die Grafik stellt durch die drei Spalten „Marktzustände“ dar, die aus einem bestimmten Zustand des Netzes abzuleiten sind

› Innerhalb dieser Netz / Marktzustände sind unterschiedliche Energie- bzw. Systemdienstleistungen erforderlich, um das Gesamtsystem möglichst im gewünschten Normalbetrieb (grüner Bereich) zu halten, wo der Markt möglichst uneingeschränkt funktionieren kann

AMPELMODELL


4,3

2,5

3,5

2,4

4,4

1,82 2

3

0

1

2

3

4

5

Kategorie 1 Kategorie 2 Kategorie 3

in M

io. E

UR

2007 2008 2009

› Ziel des INTEGRA Projektes war die Entwicklung des Domain SpecificArchitecture Model bestehend aus:

› Business Model (SGAM Business Layer)› Function Model (SGAM Function Layer)› Architecture Model (SGAM Information,

Communication und Component Layer)› Entwicklung der domänenspezifischen

Modellierungssprache (DSL), so dass eine klare Trennung der drei Teilmodelle Business-Model, Function-Model und Architecture-Model existiert

SGAM M/490 MODELL


4,3

2,5

3,5

2,4

4,4

1,82 2

3

0

1

2

3

4

5

Kategorie 1 Kategorie 2 Kategorie 3

in M

io. E

UR

2007 2008 2009

› Bei der Spezifikation dieses Metamodells wurde besonderes Augenmerk auf die Integration existierender Arbeiten wie dem IEC 62559 Use-Case-Template oder der IEC Standardsmap gelegt

› Für die Realisierung der DSL wurde kein eigenes Modellierungswerkzeug implementiert

› Programmierung als Add-In-Erweiterung für das weit verbreitete Modellierungstool „Enterprise Architect“ von Sparx Systems

META-MODELL


› Business Analysis: zielt auf die Identifikation von Business Actors, deren Business Goals (individuelle Interessen oder regulatorische Vorgaben) sowie gemeinsamer Business Cases ab

› Function Description: Auf Basis der Business Cases werden in diesem Schritt konkrete High Level Use-Cases abgeleitet

› Model Transformation: Ableitung der physischen Komponenten des Systems aus den Logical Actors bzw. aus den Business Actors

MODELLIERUNGSSPRACHE


› Information Layer: beschreibt die logischen Informationsflüsse zwischen einzelnen Komponenten und bildet diese Informationsflüsse auf konkrete Data Model Standards ab

› Communication Layer: Spezifikation der konkreten Kommunikations-Protokolle

› Component Layer: Modellierung der IKT Netzwerk-Architektur, hierfür wurden in der DSL spezifische Komponenten wie Netzwerk-Segmente, Firewalls, Router, Gateways etc. integriert

MODELLIERUNGSSPRACHE


› Integration des US-amerikanischen „NIST Logical Reference Model“, des ENTSO-E Role Models sowie des europäischen „Smart Grid Architecture Model“

› Mapping eines Bezugssystems für die Darstellung von Smart GridSystemarchitekturen mit einer konkreten Referenzarchitektur mit integriertem und erweiterbaren Security Konzept

REFERENZARCHITEKTURMapping verschiedener Konzepte


› Rein technischer Vergleich der untersuchten Regelungskonzepte ohne Berücksichtigung wirtschaftlicher Aspekte ist nur bedingt sinnvoll

› Die untersuchten Lösungen unterscheiden sich signifikant in Anschaffungs- und laufenden Kosten

› Regelbedarf in der Niederspannung bezogen sowohl auf PV-Blindleistungsregelung als auch auf RONT-Regelung ist über das gesamte Mittelspannungsnetz betrachtet sehr gering

KOORDINIERTE SPANNUNGSREGELUNG


DemosSUTs

(named)

Actuators

(control of)

Observer

(observing with)

HC-constraint

(what)

Voltage level

(where)

LV

Voltage

-

OLTCU@LV

local control of OLTC

DG DemoNet (AT)Zukunftsnetze

A(DE)

PV (Q(&P)) - localU@LV

local control of DRES

DG DemoNet (AT)

OLTC & DRES (Q(&P)) - local

U@LVlocal control of OLTC & DRES

DG DemoNet (AT)

Smart Meters

OLTC

U@LVcentralised

control of OLTCwith smart

meters

DG DemoNet (AT)

OLTC & DRES (Q(&P)) - local

U@LVcentralised

control of OLTC & DRES with smart

meters

DG DemoNet (AT)

Voltage & Current

PLF based on AMI, RTU -

U/I@LVsmart planning

with probabilistic tools

DG DemoNet (AT)

› Wird durch eine Weitbereichsregelung am UW die Spannung im gesamten Mittelspannungsnetz optimiert, so wird im koordinierten Betrieb eine Q(U)-Regelung nur mehr in sehr wenigen Niederspannungsnetzen aktiv

› Eine kombinierte Spannungsregelung auf Mittel- und Niederspannungsebene muss nicht notwendigerweise zu einer signifikanten Erhöhung der Blindleistungsflüsse im Netz führen



› Blindleistungsregelung auf einer Spannungsebene beeinflusst die Spannungssituation auf der anderen Spannungsebene positiv

› Ergebnisse der Simulationen zeigen keine signifikante Steigerung der Netzverluste durch eine spannungsebenenübergreifendeSpannungsregelung

› cosPhi(P)-Regelung verursacht viel mehr Blindleistungsflüsse als eine Q(U)-Regelung



› Marktbasierter Ansatz für die Koordination von Markt und Netz namens Flexibility Operator (FlexOp)

› Auf Basis des Ampelmodells und in Übereinstimmung mit einem dafür entworfenen regionalen Flexibilitäts-markt

› Kopplung mit dem Smart Grid Co-Simulationsframeworks Mosaik zum Test der prototypischen Umsetzung (Proof-of-Concept)

› Erweiterung des Ansatz um Smart Contracts und Blockchains möglich

DEFINITION UND ENTWICKLUNG EINES FLEXIBILITYOPERATOR


DEFINITION UND ENTWICKLUNG EINES FLEXIBILITYOPERATORBeeinflussung der Spannungsverläufe


› Building Energy Agent (BEA) als zentrale Komponente im intelligenten Gebäude

› Optimierung des Energieeinsatz in diesen Gebäuden basierend auf Einspeise- und Lastprognose

› Erhebung und Weiterleitung von Flexibilitätspotentialen an den FlexOp

› BEA realisiert Flexibilitätsanforderungen vom FlexOp durch anpassen der aktuellen Energieeinsatzpläne

› Softwarebasis OpenMUC des Frauenhofer ISE

BUILDING ENERGY AGENT


› Einsatzes eines Flexibility Operators in Kombination mit VKW-Strategien in der Fallstudie Köstendorf

› Der Kostenbenchmark einer Implementierung für einen Betrachtungszeitraum von 50 Jahren liegt bei einigen Euro bzw. im Idealfall bei wenigen hundert Euro

› State Estimation im NS-Bereich technisch möglich, aber nur dann sinnvoll, wenn keine langfristig günstigeren Alternativlösungen mehr zur Verfügung stehen

ÖKONOMISCHE BEWERTUNG UND RAHMENBEDINGUNGENInteraktion eines Virtuellen Kraftwerks mit BEA und FlexOp


› Die durch den Flexibilitätsoperator verursachten Erlöseinbußen am untersuchten Tertiärregelenergie-marktsegment hätten um ein Vielfaches steigen müssen, um Kostengleichheit im Vergleich zu einer Blindleistungsregelung zu erreichen

› Lokale Wirkleistungsbegrenzung als kostengünstigste Netzintegrationslösung in der betrachteten Fallstudie

› Etablierung kleiner Marktsegmente und darin gehandelter Dienstleistungen ist schwierig

ERGEBNISSE DER ÖKONOMISCHEN BEWERTUNG


Documents

Anleitungen zur Präsentationsvorlage der Salzburg AG€¦ · › Function Model (SGAM Function Layer) › ArchitectureModel (SGAM Information, Communication und Component Layer)