Kapitel 9: Datenarchitektur: MaStR, Lastprofile, OSM, Messpunkte und Anlagenlisten

Fachliche Erstfassung v0.9. Diese Seite ist ein Orientierungs- und Prüfrahmen; sie ersetzt keine Rechts-, Steuer-, Vergabe- oder Wirtschaftlichkeitsprüfung im Einzelfall.

Kapitel 9: Datenarchitektur: MaStR, Lastprofile, OSM, Messpunkte und Anlagenlisten

Warum Datenarchitektur eine Haushaltsfrage ist

Kommunale Energieentscheidungen scheitern selten daran, dass gar keine Daten vorhanden sind. Sie scheitern daran, dass Daten aus unterschiedlichen Welten ungeprüft zusammengeführt werden: Gebäudelisten aus dem Liegenschaftsamt, Stromrechnungen aus der Kämmerei, MaStR-Exporte aus dem Internet, Lastgänge vom Messstellenbetreiber, Netzanschlussangaben vom Verteilnetzbetreiber, Dachflächen aus GIS-Systemen, Wärmeplan-Daten, OSM-Geometrien, Anlagenlisten aus Projekten, Fördermittelakten, Lieferverträge, Beteiligungsberichte und Excel-Tabellen aus früheren Gutachten.

Für die Kämmerei ist das kein technisches Ordnungsproblem. Es ist die Vorbedingung jeder belastbaren Finanz-, Beschaffungs- und Beschlussentscheidung. Eine Kommune kann nur dann seriös über PV-Anlagen, Speicher, Ladeinfrastruktur, Wärmepumpen, Wärmenetze, Gasnetzpfade, Energy Sharing oder dynamische Strombeschaffung entscheiden, wenn sie weiß, welche Zahl welchen Gegenstand beschreibt, aus welcher Quelle sie stammt, welchen Zeitraum sie abdeckt, wer die Rolle trägt, welche Rechts- oder Vertragsbeziehung betroffen ist und ob die Zahl im Haushalt überhaupt wirkt.

Die zentrale These dieses Kapitels lautet:

Eine kommunale Energiedatenarchitektur muss nicht möglichst viele Daten sammeln. Sie muss jede entscheidungsrelevante Aussage auf Objekt, Messpunkt, Zeitraum, Rolle, Quelle, Qualität und Haushaltswirkung zurückführen.

Diese Aussage klingt nüchtern. Genau deshalb ist sie für Kämmerer wichtig. Sie verhindert, dass installierte Leistung mit Erzeugung, Jahresverbrauch mit Last, öffentliche Registerdaten mit kommunalem Eigentum, Standardlastprofile mit gemessenem Betrieb, OSM-Gebäude mit Liegenschaftsinventaren, Day-Ahead-Preise mit kommunalen Rechnungspreisen oder Zählernummern mit Marktlokationen verwechselt werden.

Kapitel 9 ist damit das Verbindungsstück des Buches. Kapitel 3 braucht es für Stromverbrauch, lokale Erzeugung und Importkostenmethodik. Kapitel 5 braucht es für kommunale Liegenschaften. Kapitel 6 und 7 brauchen es für Wärme- und Gasbestände. Kapitel 8 und 10 brauchen es für Netzbetreiberkommunikation, Messwesen und steuerbare Verbrauchseinrichtungen. Kapitel 11 und 12 brauchen es für beschlussfähige Vorlagen und ein belastbares Arbeitsprogramm.

Das Grundmodell: Eine Aussage, sieben Prüfspalten

Die wichtigste Einheit einer kommunalen Energiedatenarchitektur ist nicht die Tabelle, sondern die Aussage. Eine Aussage kann lauten: "Die Schule X verbraucht jährlich 180.000 kWh Strom." Oder: "Auf dem Dach des Bauhofs ist eine PV-Anlage mit 99 kWp installiert." Oder: "Der Standort Y hat einen Viertelstundenlastgang." Oder: "Ein Batteriespeicher kann die Lastspitze senken." Jede dieser Aussagen braucht sieben Prüfspalten.

Objekt: Worauf bezieht sich die Aussage? Auf ein Gebäude, ein Grundstück, eine Marktlokation, eine Messlokation, einen Netzanschluss, eine Anlage, einen Speicher, einen Ladepunkt, eine Kostenstelle, einen Betreiber, eine Straße oder ein Gebiet?

Messpunkt: Welche Marktlokation, Messlokation, Zählernummer, Messeinrichtung, Einspeisestelle oder Übergabestation ist betroffen? Bei Wärme und Gas entsprechend: welche Lieferstelle, Übergabestation, Wärmemengenzählung, Gaszählerstelle oder Abrechnungseinheit?

Zeitraum: Für welchen Zeitraum gilt die Zahl? Rechnungsjahr, Kalenderjahr, Lieferjahr, Monat, Viertelstunde, Stichtag, Datenexport, Planstand, Vertragslaufzeit oder Beschlussperiode?

Rolle: Wer ist Eigentümer, Betreiber, Nutzer, Letztverbraucher, Anlagenbetreiber, Lieferant, Messstellenbetreiber, Netzbetreiber, Verpächter, Contractor, Konzessionsnehmer, Haushaltsverantwortlicher oder Beteiligung?

Quelle: Woher stammt die Aussage? Rechnung, Lastgangdatei, MaStR, Netzbetreiberantwort, Messstellenbetreiberportal, Liegenschaftsregister, Wärmeplan, OSM, kommunales GIS, Vertrag, Beschlussvorlage, Gutachten, Fördermittelakte oder Schätzung?

Qualität: Ist der Wert gemessen, abgerechnet, registerbasiert, behördlich veröffentlicht, geprüft, plausibilisiert, geschätzt, modelliert, veraltet, widersprüchlich, vertraulich, nicht freigegeben oder für die konkrete Aussage ungeeignet?

Haushaltswirkung: Welche Kostenstelle, Investitionsnummer, Produktgruppe, Sachkonto, Einnahmeart, Folgekostenposition, Beteiligungswirkung, Fördermittelbindung oder Beschlussfrage wird berührt?

Diese sieben Spalten gehören in jede Energieakte. Sie machen aus einer Datensammlung ein Nachweissystem. Ohne sie bleibt unklar, ob ein Wert als Beleg, Prüfwert, Annahme, Sperre oder reine Kontextinformation zu behandeln ist.

Objektidentität: Gebäude, Grundstück, Anschluss und Organisation trennen

Die erste Datenfalle liegt in der Objektidentität. Eine kommunale Liegenschaft ist nicht immer ein Gebäude. Ein Gebäude ist nicht immer eine Kostenstelle. Eine Kostenstelle ist nicht immer ein Netzanschluss. Ein Netzanschluss ist nicht immer eine Marktlokation. Eine Adresse ist nicht immer eindeutig. Und eine organisatorische Zuständigkeit kann von Eigentum, Nutzung, Betreiberrolle und Rechnungsadresse abweichen.

Für Energieentscheidungen muss die Kommune mindestens vier Objektlogiken trennen.

Liegenschaftslogik: Sie fragt nach Grundstück, Gebäude, Gebäudeteil, Nutzung, Eigentum, Baujahr, Sanierungsstand, Dachfläche, Heizsystem, Brandschutz, Denkmalschutz, Bauunterhaltung, Flurstück und Geometrie. Diese Sicht liegt häufig im Gebäudemanagement, Bauamt oder kommunalen GIS.

Energiewirtschaftliche Logik: Sie fragt nach Netzanschluss, Marktlokation, Messlokation, Zähler, Lieferant, Messstellenbetreiber, Netzbetreiber, Lastgang, Einspeisung, Einspeiseanlage, Bilanzierung, Netzentgelt, Konzessionsabgabe und Vertragsmodell. Diese Sicht liegt häufig bei Lieferant, Netzbetreiber, Messstellenbetreiber, Stadtwerk oder Energiedienstleister.

Haushaltslogik: Sie fragt nach Kostenstelle, Produkt, Sachkonto, Investitionsmaßnahme, Fördermittel, Bewirtschaftungsbudget, Eigenbetrieb, Beteiligung, interner Leistungsverrechnung und Zuständigkeit der Bewirtschaftung. Diese Sicht liegt in Kämmerei, Fachamt, Eigenbetrieb oder Haushaltsplanung.

Betriebslogik: Sie fragt nach Nutzer, Betriebszeiten, Hausmeister, Dienstleister, Fuhrpark, Schulbetrieb, Feuerwehrbereitschaft, Sportnutzung, Wartung, Störung, Zugang und Alltag. Diese Sicht liegt oft in mehreren Ämtern und ist selten vollständig digitalisiert.

Wenn diese vier Logiken nicht sauber verbunden werden, entstehen falsche Prioritäten. Ein Gebäude kann auf dem Papier einen hohen Stromverbrauch haben, tatsächlich aber mehrere Nutzer, Untermessungen und Sonderlasten enthalten. Ein Dach kann im GIS groß wirken, aber wegen Statik, Brandschutz, Verschattung oder Sanierungsfenster nicht nutzbar sein. Eine PV-Anlage kann auf kommunalem Grund stehen, aber einem Dritten gehören. Ein Netzanschluss kann mehrere Gebäude versorgen. Eine Kostenstelle kann Verbräuche mehrerer Lieferstellen bündeln.

Die Datenarchitektur sollte deshalb mit einer kommunalen Objekt-ID arbeiten, die keine bestehende Nummer ersetzt, sondern vorhandene Nummern verknüpft. Für jedes Objekt sollten mindestens geführt werden:

• kommunale Objekt-ID,
• Adresse und Geokoordinate,
• Grundstücks- oder Flurstücksbezug, soweit verfügbar,
• Gebäudeteil und Nutzung,
• Eigentümer und Nutzer,
• zuständiges Amt,
• Kostenstelle und Haushaltsprodukt,
• Netzanschluss und Marktlokation,
• Messlokation und Zähler,
• relevante Anlagen-IDs, insbesondere MaStR-Nummern,
• Verträge und Vertragspartner,
• Datenverantwortlicher und letzter Prüfstand.

Diese Stammdaten sind nicht spektakulär. Ohne sie ist jede spätere Analyse unsicher.

MaStR: Registeranker, kein Anlageninventar der Kommune

Das Marktstammdatenregister ist ein zentraler Behördenanker für die kommunale Energiedatenarchitektur. Die Bundesnetzagentur beschreibt das MaStR als umfassendes behördliches Register für Stammdaten des Strom- und Gasmarktes. Fast alle Daten sind öffentlich zugänglich, können gefiltert, ausgewertet und heruntergeladen werden. Für Registrierungen gelten die Regeln und Fristen der Marktstammdatenregisterverordnung.

Für die Datenarchitektur sind drei Quellenebenen wichtig:

1. die öffentliche Suche und die öffentlichen Übersichten des MaStR,
2. der Gesamtdatenauszug im XML-Format, der nach MaStR-Angaben in der Regel um 5:00 Uhr auf den gültigen Datenstand aktualisiert wird,
3. die Marktstammdatenregisterverordnung als rechtlicher Rahmen.

§ 5 MaStRV verpflichtet Betreiber, Einheiten sowie EEG- und KWK-Anlagen im Marktstammdatenregister zu registrieren. Registrierungen müssen grundsätzlich innerhalb eines Monats nach Inbetriebnahme erfolgen. § 13 MaStRV beschreibt die Überprüfung gespeicherter Daten durch Netzbetreiber auf Aufforderung der Bundesnetzagentur. § 17 MaStRV ist für kommunale Arbeitsprozesse ebenfalls relevant, weil Marktakteure anderen Marktakteuren und registrierten Behörden Zugang zu sämtlichen Daten im MaStR gewähren können, die sie registriert haben und die nicht bereits öffentlich sind. Daraus folgt keine automatische kommunale Vollsicht, aber ein klarer Prüfpfad für Datenfreigaben.

Für die Kämmerei folgt daraus eine klare, aber begrenzte Nutzung:

Das MaStR ist ein Registeranker. Es beweist nicht automatisch kommunales Eigentum, tatsächliche Erzeugung, Eigenverbrauch, Haushaltswirkung oder Beschlussreife.

Ein MaStR-Eintrag beantwortet vor allem: Welche registrierte Einheit oder Anlage existiert nach Registerstand? Wo ist sie verortet? Welche technischen Stammdaten sind eingetragen? Welche Status- und Leistungsangaben sind öffentlich verfügbar? Welcher Export- oder Abrufstand wurde genutzt?

Ein MaStR-Eintrag beantwortet nicht allein:

• ob die Anlage kommunal ist,
• ob sie einem Eigenbetrieb, Stadtwerk, Contractor oder Dritten gehört,
• ob sie in einem kommunalen Haushalt wirkt,
• ob der Strom in einem kommunalen Objekt verbraucht wird,
• welche Viertelstunden-Erzeugung tatsächlich vorliegt,
• welches Messkonzept gilt,
• welche Einnahmen, Einsparungen oder Folgekosten entstehen,
• ob die Anlage vollständig, fehlerfrei oder aktuell im Register geführt ist.

Die kommunale Arbeitsregel lautet deshalb: Jeder MaStR-Fund wird zuerst als Anlagenhypothese geführt. Aus der Hypothese wird erst dann ein kommunaler Nachweis, wenn Betreiberrolle, Objektzuordnung, Netzanschluss, Zählerkonzept, Abrechnung, Vertrag und tatsächliche Erzeugungs- oder Einspeisedaten abgeglichen sind.

Ein reproduzierbarer MaStR-Abgleich sollte mindestens diese Schritte enthalten:

1. Gebiet und Stichtag festlegen. Gemeindegebiet, Ortsteil, Flurstückskulisse oder Objektliste definieren; Exportdatum und Uhrzeit dokumentieren.
2. Originalexport sichern. XML-Datensatz oder nachvollziehbaren Filter mit Hash, Ablageort und Versionsnotiz ablegen.
3. Adress- und Geoprüfung durchführen. Registerstandort gegen kommunale Adressen, Flurstücke, Gebäude, Luftbilder, bekannte Anlagen und Ortskenntnis prüfen.
4. Dubletten und Status prüfen. Inbetriebnahme, Anlagenstatus, Energieträger, Nettonennleistung, Betreiberangabe und etwaige Mehrfacheinträge markieren.
5. Rollenklärung vornehmen. Betreiber, Eigentümer, Nutzer, Vertragspartner, Stadtwerk, Eigenbetrieb, Contractor und Haushaltsverantwortung trennen.
6. Mess- und Vertragsabgleich herstellen. Marktlokation, Messlokation, Zähler, Einspeisung, Eigenverbrauch, Vergütung, Liefervertrag, Pacht oder Dienstleistung prüfen.
7. Statusentscheidung setzen. Anlage als kommunal belegt, kommunal relevant, Beteiligungsfall, Drittanlage, unklar, veraltet oder gesperrt markieren.

Gerade der letzte Schritt ist wichtig. Eine Anlagenliste ohne Statusentscheidung lädt zu Fehlinterpretationen ein. Ein Kämmerer braucht nicht nur den Anlagenfund, sondern den Prüfstatus.

Messpunktlogik: Marktlokation, Messlokation und Zähler nicht vermischen

Kommunale Energieprojekte beginnen häufig mit Zählernummern. Das ist nachvollziehbar, aber unzureichend. Eine Zählernummer kann sich ändern. Eine Rechnung kann mehrere Informationen bündeln. Eine Marktlokation beschreibt die energiewirtschaftliche Verbrauchs- oder Einspeisestelle. Eine Messlokation beschreibt die messtechnische Erfassung. Der physische Zähler ist ein Bestandteil der Messinfrastruktur, aber nicht die ganze energiewirtschaftliche Beziehung.

Für Beschlussvorlagen muss klar sein, welche Ebene gemeint ist. Diese Trennung ist besonders wichtig, wenn eine Kommune Eigenverbrauch, Gebäudestrom, Energy Sharing, steuerbare Verbrauchseinrichtungen, Speicher, Ladepunkte, Wärmepumpen oder dynamische Tarife prüft. In diesen Fällen reicht die Jahresabrechnung nicht. Die Kommune muss wissen, wo Energie entnommen, eingespeist, gemessen, bilanziert, gesteuert und abgerechnet wird.

Das Messstellenbetriebsgesetz zeigt, warum diese Unterscheidung keine Formalie ist. § 55 MsbG ordnet für Letztverbraucher mit einem Jahresstromverbrauch über 100.000 kWh eine Zählerstandsgangmessung oder, soweit erforderlich, eine viertelstündige registrierende Lastgangmessung an. Für Letztverbraucher mit intelligentem Messsystem sowie für steuerbare Verbrauchseinrichtungen nach § 14a EnWG gelten eigene Messlogiken. Bei Erzeugungs- und Verbrauchssituationen an einem Anschlusspunkt sind entnommene und eingespeiste sowie, soweit angeordnet, verbrauchte und erzeugte Energie in einem einheitlichen Verfahren zu messen.

§ 60 MsbG macht die organisatorische Konsequenz sichtbar. Der Messstellenbetreiber hat die nach §§ 55 bis 59 erhobenen Daten aufzubereiten und im erforderlichen Umfang an berechtigte Stellen zu übermitteln. Für bestimmte Fälle werden Last-, Zählerstands- oder Einspeisegänge täglich für den Vortag und unter bestimmten Anforderungen auch viertelstündlich übermittelt. Außerhalb der geregelten Fälle dürfen Dritten im Rahmen von Zusatzleistungen anonymisierte und geeignet aggregierte Last-, Zählerstands- und Einspeisegänge bereitgestellt werden. Personenbezogene Messwerte sind zu löschen oder zu anonymisieren, sobald sie für die Aufgabenwahrnehmung nicht mehr erforderlich sind, spätestens nach den gesetzlichen Fristen, soweit keine Festlegung etwas anderes bestimmt.

Die Bundesnetzagentur hat zudem mit BK6-24-174 die Datenübermittlung von Zählerstandsgängen ab dem 06.06.2025 in der Marktkommunikation konkretisiert. Für kommunale Datenarchitektur bedeutet das: Viertelstunden- oder Zählerstandsgangdaten sind nicht nur technische Dateien. Sie sind Prozess-, Rollen- und Berechtigungsdaten.

Eine kommunale Messpunktliste sollte daher mindestens enthalten:

• Marktlokations-ID,
• Messlokations-ID,
• Zählernummer und Zählerart,
• Netzanschluss und Adresse,
• Netzbetreiber,
• Messstellenbetreiber,
• Lieferant,
• Letztverbraucher oder Anlagenbetreiber,
• Kostenstelle und Haushaltsprodukt,
• Messverfahren, etwa SLP, RLM, iMSys oder Zählerstandsgang,
• Datenauflösung und Datenverfügbarkeit,
• Beginn und Ende des Liefer-, Mess- oder Bilanzierungszeitraums,
• Zuordnung zu Gebäude, Anlage, Ladepunkt, Wärmepumpe, Speicher oder sonstiger Nutzung,
• Datenschutz-, Zugriffs- und Freigabestatus,
• letzte geprüfte Rechnung oder Messwertlieferung.

Ohne diese Liste lassen sich Energiezahlen nicht zuverlässig mit Rechnungen, Anlagen, Verträgen und Beschlüssen verbinden.

Lastprofile: SLP ist kein gemessener Betrieb

Standardlastprofile sind ein wichtiges Instrument des Strommarktes. Sie dürfen in kommunalen Energieanalysen aber nicht als echte Lastgänge missverstanden werden. Der BDEW stellt 2025 aktualisierte Standardlastprofile Strom und eine Anwendungshilfe bereit. Nach BDEW-Hinweisen stehen die Profile als freiwillige Unterstützung für die Strombilanzierung zur Verfügung; Netzbetreiber können weiterhin aktualisierte Profile, alte Profile, eigene Profile oder Mischungen verwenden.

Für die Kämmerei ist die Grenze entscheidend: Ein Standardlastprofil kann für Bilanzierung, Prognose, erste Plausibilisierung und Lückenfüllung geeignet sein. Es zeigt aber nicht, wie die konkrete Schule, das konkrete Rathaus oder der konkrete Bauhof an einem bestimmten Dienstag tatsächlich geladen, geheizt, gekühlt, eingespeist oder produziert hat.

Die kommunale Datenarchitektur sollte deshalb drei Lastdatenklassen unterscheiden.

Gemessene Zeitreihe: RLM-, Zählerstandsgang-, Einspeisegang- oder iMSys-Daten mit Zeitstempel, Messpunkt, Einheit, Fehlwertstatus und Quelle. Diese Daten sind für Lastspitzen, Eigenverbrauch, Speicher, steuerbare Verbrauchseinrichtungen, dynamische Tarife, Energy Sharing und Netzanschlussfragen besonders wertvoll.

Abgerechneter Jahres- oder Monatswert: Rechnungs- oder Ablesewert mit Zeitraum, Tarif, Preisbestandteilen und Messpunktbezug. Diese Daten sind für Haushalts- und Kostenabgleich wichtig, zeigen aber keine Laststruktur.

Profilierter Wert: Standardlastprofil oder Ersatzprofil, skaliert aus Jahresverbrauch, Nutzungsart oder Netzbetreiberzuordnung. Diese Daten sind für erste Modelle und Vorprüfungen geeignet, müssen aber als Modell gekennzeichnet werden.

Für Beschlüsse gilt: Je stärker eine Maßnahme von Zeitgleichheit, Lastspitzen, Flexibilität oder Preisfenstern abhängt, desto weniger reicht ein Standardlastprofil. Eine PV-Eigenverbrauchsrechnung, ein Speicher-Business-Case, ein §-14a-Prüfpfad, ein dynamischer Tarif, ein Lademanagement oder ein Energy-Sharing-Modell brauchen echte oder belastbar simulierte Zeitreihen mit offengelegten Annahmen. Fehlen diese Daten, darf die Vorlage nur einen Prüfauftrag, eine Datenerhebung oder eine Vorplanung beschließen.

SMARD, EnWG § 111d und § 111g: Marktdaten sind Kontext, nicht Rechnung

SMARD ist für Kapitel 9 relevant, weil es ein Beispiel für gut zugängliche, behördlich verankerte Marktdaten ist. § 111d EnWG verpflichtet die Bundesnetzagentur zum Betrieb einer nationalen Informationsplattform mit aktuellen Informationen insbesondere zu Erzeugung, Last, Importen, Exporten, Netz- und Anlagenverfügbarkeit sowie grenzüberschreitenden Kapazitäten. Die Daten werden in aggregierter Form für die Gebotszone der Bundesrepublik Deutschland veröffentlicht und müssen frei zugänglich sein.

Zugleich ist die Rechtslage dynamisch. § 111g EnWG sieht vor, dass die Bundesnetzagentur spätestens ab dem 29.12.2026 eine nationale Transparenzplattform betreibt, die aktuelle energiewirtschaftliche Daten insbesondere zu Erzeugung, Transport, Handel, Vertrieb oder Verbrauch von Elektrizität, Gas oder Wasserstoff bereitstellt. Personenbezogene Daten sind davon nicht umfasst; Betriebs- und Geschäftsgeheimnisse werden in der Regel nicht veröffentlicht, und Aggregierung, Anonymisierung sowie zeitlich verzögerte Veröffentlichung sind ausdrücklich als Schutzmaßnahmen angelegt.

Für den Stand dieses Kapitels am 15.07.2026 heißt das:

SMARD und die künftige Transparenzplattform liefern Markt- und Systemkontext. Sie ersetzen keine lokale Messstelle, keinen Liefervertrag, keine kommunale Rechnung und keine Beschlussakte.

Marktdaten sind geeignet für:

• nationale Erzeugungs-, Last-, Import- und Exportentwicklungen,
• Day-Ahead-Preise als Großhandelssignal,
• Plausibilisierung von Zeitfenstern,
• Erklärung von Strommarktzusammenhängen,
• Abgrenzung von Systemdaten und lokalen Haushaltsdaten,
• Sensitivitätsrechnungen, wenn ihre Grenzen offen ausgewiesen werden.

Marktdaten sind nicht geeignet für:

• konkrete Stromkosten einer Kommune ohne Liefervertrag,
• Eigenverbrauchsquote einer Liegenschaft ohne Messpunktdaten,
• lokale Erzeugung aus MaStR-Anlagen ohne tatsächliche Erzeugungszeitreihe,
• Einsparversprechen aus dynamischen Tarifen ohne lokale Laststeuerung,
• Beschlussreife von Speichern oder Ladeinfrastruktur ohne Standort-, Anschluss- und Vertragsdaten.

Die Datenarchitektur sollte daher eine klare Quellenklasse "Marktdaten" führen. Diese Klasse darf als Kontext, Vergleich, Plausibilisierung oder Szenario verwendet werden. Sie darf nicht stillschweigend in "kommunaler Ist-Wert" umbenannt werden.

Für diesen Lauf wurde Cernion read-only als Marktsignalwerkzeug genutzt. Der Evidence Router empfahl für aktuelle DE-LU-Day-Ahead-Preise den Endpoint /api/entsoe/day-ahead-prices. Die Abfrage für 2026-07-15/16 lieferte 95 Viertelstundenwerte mit Minimum 48,97 EUR/MWh, Maximum 203,78 EUR/MWh, Durchschnitt 132,10 EUR/MWh und Median 140,00 EUR/MWh. Diese Werte zeigen die methodische Bedeutung von Zeitfenstern. Sie sind keine kommunalen Stromkosten, keine Einsparung, kein Erlös, kein Netzentgelt, keine §-14a-Wirkung und kein Haushaltsnachweis.

OSM und GIS: Gute Geodaten, aber kein amtliches Liegenschaftsregister

OpenStreetMap ist für kommunale Energieanalysen nützlich. Es kann Gebäudekörper, Straßen, Flächennutzungen, Orientierung, Umfeld, Wegebeziehungen und erste Geometrien liefern. OpenStreetMap-Daten stehen als offene Daten unter der Open Database License. Bei Nutzung sind Attribution und Lizenzbedingungen zu beachten.

Für die Kämmerei ist OSM aber kein amtliches Liegenschaftsregister. Ein Gebäudepolygon in OSM kann fehlen, veraltet, ungenau, falsch attribuiert oder ohne Nutzungsinformation sein. Es sagt nichts über Eigentum, Dachstatik, Brandschutz, Denkmalschutz, Sanierungszustand, Hausanschluss, Zähler, Betreiber, Mietverhältnisse oder Haushaltsstelle.

Die richtige Rolle von OSM und GIS liegt in drei Bereichen.

Geometrischer Einstieg: Gebäudeumrisse, Lage, Nachbarschaft, Wege und Flächen können helfen, Objekte zu identifizieren, Dachflächen grob zu prüfen oder Wärmenetzkorridore zu visualisieren.

Plausibilisierung: OSM-Daten können mit kommunalem GIS, ALKIS, Liegenschaftsregister, Bauakten, Energieausweisen, Dachkataster, Luftbildern und Ortskenntnis abgeglichen werden. Abweichungen sind Hinweise auf Prüfbedarf.

Kommunikation: Karten helfen Rat, Verwaltung und Öffentlichkeit, Energiefragen räumlich zu verstehen. Sie dürfen aber nur mit korrektem Quellen- und Lizenzhinweis und ohne Überdehnung der Aussagekraft verwendet werden.

Für diesen Lauf wurde Cernion OSM-Grid-Kontext für Heidelberg read-only abgefragt. Die Abfrage lieferte keine belastbare Mittelspannungs-Evidence. Das ist keine Aussage darüber, dass keine Netzinfrastruktur vorhanden ist. Es ist nur eine Aussage über die Nichtverwendbarkeit dieser OSM-Abfrage als Nachweis. Fehlende OSM-Objekte, fehlende Spannungstags oder ein abgebrochener Substation-Finder ersetzen weder Netzverträglichkeitsprüfung noch Betreiberantwort noch Anschlusskapazitätszusage.

Für die Datenarchitektur sollte jede Geodatenquelle nach Status markiert werden:

• amtliche kommunale Geodaten,
• öffentliches Open-Data-Angebot,
• OSM oder Community-Daten,
• Luftbild- oder Fernerkundungsableitung,
• Gutachter- oder Dienstleistermodell,
• manuell gezeichnete Arbeitsgeometrie,
• Betreiber- oder Infrastrukturkarte mit Nutzungsbeschränkung.

Diese Statusspalte verhindert, dass eine optisch überzeugende Karte mehr Beweiskraft erhält als ihr zusteht.

Anlagenlisten: Aus Einzelquellen wird ein Energie-Asset-Register

Das wichtigste fehlende Element in vielen Kommunen ist eine belastbare Energie-Asset-Liste. Sie umfasst nicht nur PV-Anlagen. Sie umfasst Stromerzeuger, Speicher, Ladepunkte, Wärmepumpen, Kälteanlagen, Heizkessel, Wärmenetzanschlüsse, Übergabestationen, Blockheizkraftwerke, Notstromanlagen, Steuerboxen, Energiemanagementsysteme, Messstellen und größere Verbraucher.

Eine solche Liste darf nicht nur technische Spalten enthalten. Sie muss organisatorisch und haushalterisch lesbar sein. Mindestfelder sind:

• Asset-ID und Objektbezug,
• Asset-Kategorie,
• Standort und Gebäudeteil,
• technische Leistung, Kapazität oder Anschlusswert,
• Inbetriebnahmedatum und Status,
• Eigentümer,
• Betreiber,
• Nutzer oder begünstigte Organisationseinheit,
• Netzanschluss, Marktlokation und Messlokation,
• MaStR-ID, soweit relevant,
• Wartungs- und Betriebsvertrag,
• Liefer-, Einspeise-, Pacht-, Contracting- oder Dienstleistungsvertrag,
• Fördermittel- oder Vergütungsstatus,
• Haushaltsstelle oder Beteiligungsbezug,
• Datenquelle und letzter Prüfstand,
• offene Sperren.

Die offene Sperre ist keine Schwäche, sondern eine Steuerungsinformation. Ein Speicher ohne Messkonzept, eine PV-Anlage ohne Betreiberklärung, ein Ladepunkt ohne Netzbetreiberantwort, eine Wärmepumpe ohne Anschlussleistungsprüfung oder ein Energiemanagementsystem ohne Datenzugriff ist kein fertiger Datensatz. Es ist ein Arbeitsauftrag.

Cernion Energy Tools wurden für dieses Kapitel read-only geprüft. Der Evidence Router fand keinen passenden Endpunkt für kommunale Asset-Tabellen, Anlagenlisten, Messpunkte oder lokale Lastgänge. Die Knowledge-RAG-Abfrage lieferte methodische Hinweise, aber nach eigener Evidenzbewertung keine ausreichende Primärquellenstütze für harte Rechts-, Rollen- oder Prozesspflichten. Daher wurden keine Cernion-Rechtsbewertungen, lokalen Asset-Fakten, lokalen Netzbehauptungen oder kommunalen Haushaltszahlen übernommen.

Diese Begrenzung passt zur Kapitelthese: Ein Datenwerkzeug kann die Struktur verbessern, aber fehlende lokale Primärdaten nicht ersetzen.

Datenschutz und Datenberechtigung: Nicht jede nützliche Zahl darf frei wandern

Energiedaten können personenbezogen, betriebsrelevant, sicherheitsrelevant oder vertraulich sein. Das gilt besonders bei Messwerten, Lastgängen, Nutzungsprofilen, Betreiberinformationen, kritischer Infrastruktur, Feuerwehr- und Betriebsstandorten, Mietern, Schulen, Vereinen und Wohngebäuden. Eine kämmereitaugliche Datenarchitektur muss deshalb nicht nur fragen, ob Daten vorhanden sind, sondern ob sie für den konkreten Zweck verarbeitet, zusammengeführt, intern verteilt und veröffentlicht werden dürfen.

§ 49 MsbG nennt berechtigte Stellen zur Verarbeitung personenbezogener Daten aus dem Messwesen. § 50 MsbG begrenzt Zulässigkeit und Umfang der Verarbeitung auf Einwilligung oder erforderliche Zwecke, etwa Vertragserfüllung, rechtliche Verpflichtungen, Netzbetrieb, Belieferung, Abrechnung, Bilanzierung, Registerpflichten, Flexibilitätsvermarktung, §-14a-Steuerung oder variable Tarife. § 60 MsbG konkretisiert Übermittlung, sternförmige Kommunikation sowie Löschung oder Anonymisierung.

Für die Kommune entsteht daraus eine praktische Governance-Regel:

Datenzugang ist kein Besitzrecht. Jede Nutzung braucht Zweck, Rolle, Berechtigung, Datensparsamkeit und Lösch- oder Archivierungsregel.

Die Datenarchitektur sollte deshalb für jede Datenklasse festhalten:

• Zweck der Verarbeitung,
• Rechts- oder Vertragsgrundlage,
• Datenverantwortlicher,
• Empfänger und Zugriffskreis,
• Aggregationsgrad,
• Personenbezug oder Vertraulichkeitsstatus,
• Speicherort,
• Aufbewahrungs- und Löschregel,
• Freigabe für interne Vorlage, nicht öffentlichen Draft, öffentliche Veröffentlichung oder gesperrte Nutzung.

Gerade im Buchprojekt ist diese Trennung wichtig. Auch in öffentlichen Fassungen dürfen lokale Messwerte, Verträge oder personenbezogene Informationen nicht ungeprüft in einen redaktionellen Text oder eine Beschlussvorlage wandern. Für eine Veröffentlichung sind aggregierte, anonymisierte oder ausdrücklich freigegebene Werte zu verwenden.

Datenqualität: Ein Ampelsystem mit Abbruchpunkten

Ein Energiedatenraum wird nicht dadurch besser, dass alle Felder gefüllt sind. Er wird besser, wenn jedes Feld seinen Qualitätsstatus trägt. Für kommunale Entscheidungen reicht ein einfaches Ampelsystem, wenn es konsequent verwendet wird.

Grün: belegt und entscheidungsfähig. Die Quelle ist benannt, der Zeitraum passt, der Messpunkt ist zugeordnet, die Rolle ist geklärt, der Wert ist aktuell genug und die Haushaltswirkung ist nachvollziehbar.

Gelb: plausibel, aber prüfbedürftig. Die Quelle ist vorhanden, aber unvollständig; Zeitraum, Rolle, Messpunkt, Vertragsbezug oder Datenqualität sind nicht vollständig geklärt. Der Wert darf für Vorprüfung, Priorisierung oder Szenario verwendet werden, aber nicht als harte Haushaltszahl.

Rot: gesperrt. Die Quelle fehlt, widerspricht anderen Quellen, ist veraltet, nicht freigegeben, personenbezogen ohne Berechtigung, methodisch unpassend oder für die konkrete Aussage ungeeignet. Der Wert darf nicht zur Begründung eines Umsetzungsbeschlusses verwendet werden.

Grau: nicht erforderlich. Die Information ist für die konkrete Entscheidung nicht nötig oder würde Scheingenauigkeit erzeugen.

Dieses Ampelsystem braucht Abbruchpunkte. Ein Abbruchpunkt ist die Stelle, an der eine Rechnung, Bewertung oder Vorlage bewusst nicht weitergeführt wird. Beispiele:

• MaStR-Fund ohne Betreiberklärung: keine kommunale Erzeugungsaussage.
• Jahresverbrauch ohne Lastgang: keine Speicher- oder Lastspitzenrechnung.
• OSM-Dachfläche ohne kommunale Objektprüfung: keine PV-Investitionsentscheidung.
• Day-Ahead-Preis ohne Liefervertrag: keine kommunale Stromkostenersparnis.
• Ladepunktliste ohne Netzanschlussdaten: keine §-14a- oder Netzentgeltbewertung.
• Wärmeplan-Gebiet ohne Betreiberangebot: keine Anschlusskostenentscheidung.
• Messdaten ohne Berechtigung: keine Auswertung und keine Veröffentlichung.
• Netzkarte ohne Betreiberbestätigung: keine Anschlusskapazitätsannahme.

Abbruchpunkte sind für Kämmerer hilfreich, weil sie Beschlüsse nicht verhindern, sondern richtig begrenzen. Aus "Umsetzung" wird dann "Datenerhebung", "Netzbetreiberklärung", "Variantenprüfung", "Vorplanung" oder "Rückkehr ins Gremium".

Datenraum und Verantwortlichkeiten

Eine gute Datenarchitektur braucht im ersten Schritt keine perfekte zentrale Plattform. Sie braucht klare Verantwortlichkeiten. Die Kommune sollte einen Datenraum definieren, in dem fachliche Daten zusammengeführt werden, ohne Zuständigkeiten zu verwischen.

Ein arbeitsfähiges Modell unterscheidet fünf Rollen.

Datenhalter: Stelle, bei der die Daten entstehen oder originär liegen, etwa Gebäudemanagement, Kämmerei, Netzbetreiber, Messstellenbetreiber, Lieferant, Stadtwerk, Eigenbetrieb oder Dienstleister.

Datenverantwortlicher: Stelle, die für Richtigkeit, Aktualität und Freigabe im kommunalen Arbeitsstand verantwortlich ist.

Fachprüfer: Stelle, die die energiewirtschaftliche, technische, rechtliche, datenschutzrechtliche oder haushalterische Bedeutung bewertet.

Nutzer der Entscheidung: Rat, Ausschuss, Verwaltungsvorstand, Fachamt, Eigenbetrieb oder Beteiligung.

Archiv- und Nachweisverantwortlicher: Stelle, die Versionen, Quellen, Beschlussstände und spätere Prüfungen nachvollziehbar hält.

In kleineren Kommunen können mehrere Rollen in einer Person liegen. Trotzdem sollten sie im Datenmodell getrennt bleiben. Sonst ist unklar, ob ein Wert fachlich geprüft, nur geliefert oder bereits politisch entschieden wurde.

Mindestarchitektur: Die fünf Kernregister

Für den Einstieg reicht eine überschaubare Mindestarchitektur. Sie besteht aus fünf Kernregistern, die über stabile IDs miteinander verbunden sind.

1. Objektregister: Gebäude, Grundstücke, Liegenschaften, technische Standorte, Nutzung, Eigentum, Zuständigkeit, Kostenstelle, Geometrie und Datenqualität.

2. Messpunktregister: Marktlokationen, Messlokationen, Zähler, Netzanschluss, Netzbetreiber, Messstellenbetreiber, Lieferant, Messverfahren, Datenauflösung und Zeitraum.

3. Asset-Register: Erzeugungsanlagen, Speicher, Ladepunkte, Wärmepumpen, Wärmeerzeuger, Übergabestationen, EMS, Steuertechnik, kritische Verbraucher und relevante Großverbraucher.

4. Zeitreihenregister: Strombezug, Einspeisung, Erzeugung, Wärmeverbrauch, Gasverbrauch, Lastgänge, Zählerstandsgänge, Preisreihen, Wetter- oder Nutzungsparameter, jeweils mit Quelle, Einheit, Zeitauflösung, Zeitzone und Fehlwertstatus.

5. Entscheidungsregister: Beschlüsse, Prüfaufträge, offene Sperren, Haushaltsstellen, Verträge, Vergaben, Zuständigkeiten, Fristen, Wiedervorlagen und Reviewstatus.

Die technische Umsetzung kann einfach beginnen: strukturierte Tabellen, ein Dokumentenablagekonzept, klare Dateinamen, Versionsstände und ein Nachweisregister. Entscheidend ist, dass die Verknüpfungen stabil sind. Wenn später eine Datenplattform, ein GIS, ein Energiemanagementsystem oder ein Cernion-/STROMDAO-naher Datenprozess hinzukommt, kann er auf dieser Struktur aufsetzen.

Reproduzierbare Arbeitsakte: Mindestfelder für lokale Datenpakete

Ein lokales Datenpaket sollte so aufgebaut sein, dass ein Dritter den Stand nachvollziehen kann, ohne die ursprüngliche Sachbearbeitung zu kennen. Für jede Auswertung gehören mindestens folgende Metadaten in die Arbeitsakte:

• Zweck der Auswertung,
• betroffene Objekte und Objekt-IDs,
• räumliche Kulisse und Filter,
• Datenquelle und Abrufdatum,
• Stichtag oder Zeitraum,
• Zeitzone und Zeitauflösung,
• Maßeinheit,
• Originaldatei oder Link,
• Bearbeitungsschritte,
• Prüfer und Freigabestatus,
• bekannte Lücken,
• Sperrvermerke,
• zulässige Verwendung in Vorlage, nicht öffentlichem Draft oder Veröffentlichung.

Besonders wichtig ist die Trennung von Originaldaten, bereinigten Daten und abgeleiteten Kennzahlen. Der Originalexport bleibt unverändert. Die Bereinigung wird dokumentiert. Die Kennzahl erhält einen Rechenweg. Nur so lässt sich später prüfen, ob eine Zahl wegen neuer Daten, geänderter Methodik oder falscher Annahme angepasst werden muss.

Beispiel: Aus 15 offenen Nachweisen wird ein Arbeitsplan

Ein typischer kommunaler Prüfpunkt lautet: "PV, Speicher und Ladepunkte am Bauhof prüfen." Ohne Datenarchitektur klingt das nach einer technischen Machbarkeitsstudie. Mit Datenarchitektur wird daraus ein Arbeitsplan.

Die offenen Nachweise lauten:

1. Objekt-ID, Adresse, Gebäudeteile und Grundstücksbezug des Bauhofs.
2. Zuständiges Amt, Nutzer, Betriebszeiten und Fuhrparkprofil.
3. Strom-Marktlokation, Messlokation und Zähler.
4. Jahresverbrauch und verfügbare Viertelstundenwerte.
5. Anschlussleistung und Netzbetreiberangaben.
6. Liefervertrag, Preisbestandteile und Laufzeit.
7. Dachflächen, Statik, Brandschutz, Sanierungsfenster und Verschattung.
8. MaStR-Abgleich für bestehende Anlagen am Standort.
9. Geplante PV-Leistung und Betreiberrolle.
10. Ladepunkte, Fahrzeugklassen, Ladezeiten und Mindestverfügbarkeit.
11. Speicherzweck, Kapazität, Leistung, Betriebsstrategie und Reservelogik.
12. §-14a-Einordnung, Mess- und Steuerungskonzept.
13. Investition, Betriebskosten, Wartung, EMS und Messstellenkosten.
14. Haushaltsstellen, Fördermittel und Vergabepfad.
15. Datenschutz-, Zugriffs- und Veröffentlichungsstatus der Daten.

Jeder Nachweis erhält eine Ampel und einen Datenhalter. Daraus entsteht keine fertige Umsetzung, aber eine beschlussfähige Vorstufe. Der Rat kann entscheiden, ob die Verwaltung diese Nachweise beschaffen, eine Vorplanung beauftragen oder eine Variante vertiefen soll. Das ist besser als eine pauschale Wirtschaftlichkeitsrechnung, die fehlende Daten verdeckt.

Beschlussreife-Gate für Kapitel 9

Eine kommunale Energieentscheidung ist datenarchitektonisch beschlussreif, wenn folgende Fragen beantwortet sind:

1. Welche Objekte, Messpunkte, Anlagen und Haushaltsstellen sind eindeutig betroffen?
2. Welche Daten stammen aus Primärquellen, welche aus Registern, welche aus Modellen und welche aus Schätzungen?
3. Welcher Zeitraum, welche Datenauflösung, welche Zeitzone und welcher Stichtag gelten?
4. Sind Marktlokation, Messlokation, Zähler und Kostenstelle zusammengeführt?
5. Sind MaStR-Funde mit Betreiberrolle, Objektbezug, Netzanschluss und tatsächlichen Erzeugungs- oder Einspeisedaten abgeglichen?
6. Sind Lastprofile als Modell und gemessene Lastgänge als Messdaten getrennt?
7. Sind OSM-, GIS- und Gebäudedaten nach Quellenstatus markiert?
8. Sind Datenschutz, Einwilligung, Berechtigung, Zugriff und Veröffentlichungsfähigkeit geklärt?
9. Sind fehlende Daten als Sperre oder Prüfauftrag markiert?
10. Ist erkennbar, welche Zahl im Haushalt wirkt und welche nur System-, Klima-, Standort- oder Szenariokontext ist?
11. Gibt es eine verantwortliche Stelle für Aktualisierung, Versionierung und Wiedervorlage?
12. Ist der Beschluss passend begrenzt, falls eine dieser Fragen offen bleibt?

Wenn diese Fragen nicht beantwortet sind, ist die Entscheidung nicht automatisch falsch. Sie ist nur nicht umsetzungsreif. Dann gehört in die Vorlage kein Umsetzungsbeschluss, sondern ein begrenzter Prüf-, Daten- oder Planungsauftrag.

Zusammenfassung für Kämmerer

Datenarchitektur ist die stille Infrastruktur der kommunalen Energiewende. Sie entscheidet, ob ein Stromlagebild belastbar ist, ob ein Liegenschaftsprojekt haushaltsreif wird, ob Speicher- und Flexibilitätsrechnungen tragen, ob Wärme- und Gasentscheidungen nachvollziehbar bleiben und ob der Rat zwischen politischem Ziel, technischer Möglichkeit und finanzieller Wirkung unterscheiden kann.

Die wichtigsten Regeln sind:

• MaStR ist ein Registeranker, kein kommunaler Eigentums- oder Erzeugungsbeweis.
• SLP ist ein Bilanzierungs- und Prognoseinstrument, kein gemessener Betrieb eines konkreten Gebäudes.
• SMARD und §-111g-Transparenzdaten sind Markt- und Systemkontext, keine kommunale Rechnung.
• OSM ist ein hilfreicher Geodatenbaustein, kein amtliches Liegenschaftsregister.
• Marktlokation, Messlokation, Zähler, Kostenstelle und Objekt müssen getrennt und verknüpft werden.
• Jede lokale Zahl braucht Quelle, Zeitraum, Rolle, Qualitätsstatus und Haushaltsbezug.
• Fehlende Daten sind nicht peinlich; sie sind der Arbeitsplan.

Für die Kämmerei ist die beste Datenarchitektur nicht die größte Datenbank. Es ist die Struktur, die eine klare Antwort ermöglicht: Diese Aussage ist belegt, diese ist plausibel, diese ist gesperrt, und diese Lücke muss vor der nächsten Entscheidung geschlossen werden.

Quellen- und Prüfstand

• EnWG § 111d, nationale Informationsplattform, Gesetze im Internet, Abruf 2026-07-15: https://www.gesetze-im-internet.de/enwg_2005/__111d.html
• EnWG § 111g, nationale Transparenzplattform ab spätestens 29.12.2026, Gesetze im Internet, Abruf 2026-07-15: https://www.gesetze-im-internet.de/enwg_2005/__111g.html
• MaStRV § 5, Registrierung von Einheiten und Anlagen, Gesetze im Internet, Abruf 2026-07-15: https://www.gesetze-im-internet.de/mastrv/__5.html
• MaStRV § 13, Überprüfung gespeicherter Daten durch Netzbetreiber, Gesetze im Internet, Abruf 2026-07-15: https://www.gesetze-im-internet.de/mastrv/__13.html
• MaStRV § 17, Nutzung des Marktstammdatenregisters und Datenfreigaben, Gesetze im Internet, Abruf 2026-07-15: https://www.gesetze-im-internet.de/mastrv/__17.html
• Bundesnetzagentur, Marktstammdatenregister, Abruf 2026-07-15: https://www.bundesnetzagentur.de/DE/Fachthemen/ElektrizitaetundGas/Monitoringberichte/Marktstammdatenregister/start.html
• Marktstammdatenregister, Datendownload, XML-Gesamtdatenauszug und Aktualisierungslogik, Abruf 2026-07-15: https://www.marktstammdatenregister.de/MaStR/Datendownload
• MsbG § 49, Verarbeitung personenbezogener Daten, Gesetze im Internet, Abruf 2026-07-15: https://www.gesetze-im-internet.de/messbg/__49.html
• MsbG § 50, Zulässigkeit und Umfang der Verarbeitung von Daten, Gesetze im Internet, Abruf 2026-07-15: https://www.gesetze-im-internet.de/messbg/__50.html
• MsbG § 55, Messwerterhebung Strom, Gesetze im Internet, Abruf 2026-07-15: https://www.gesetze-im-internet.de/messbg/__55.html
• MsbG § 60, Datenübermittlung, sternförmige Kommunikation, Löschung oder Anonymisierung, Gesetze im Internet, Abruf 2026-07-15: https://www.gesetze-im-internet.de/messbg/__60.html
• Bundesnetzagentur, BK6-24-174 Datenübermittlung Zählerstandsgang, Abruf 2026-07-15: https://www.bundesnetzagentur.de/DE/Beschlusskammern/1_GZ/BK6-GZ/2024/BK6-24-174/BK6-24-174_Verfahren.html
• Bundesnetzagentur, BK6-20-160 Marktkommunikation 2022, Abruf 2026-07-15: https://www.bundesnetzagentur.de/DE/Beschlusskammern/1_GZ/BK6-GZ/2020/BK6-20-160/BK6-20-160_beschluss.html
• BDEW, Standardlastprofile Strom, aktualisierte SLP 2025 und Anwendungshilfe, Abruf 2026-07-15: https://www.bdew.de/energie/standardlastprofile-strom/
• SMARD, Datennutzung, Abruf 2026-07-15: https://www.smard.de/home/datennutzung
• OpenStreetMap, Copyright and License / ODbL, Abruf 2026-07-15: https://www.openstreetmap.org/copyright
• Cernion Energy Tools read-only, Abruf 2026-07-15: Evidence Router, Knowledge RAG, OSM-Grid-Kontext und /api/entsoe/day-ahead-prices. Kein belastbarer Cernion-Nachweis für lokale Asset-Tabellen, Messpunktlisten, Lastgänge, Netzkapazitäten oder kommunale Haushaltswerte; Day-Ahead-Werte nur als Marktsignal verwendet.

BookStack-Notizen

BookStack-Ort:

• Book: Der Kämmerer und die Energiewende
• Page: Kapitel 9: Datenarchitektur: MaStR, Lastprofile, OSM, Messpunkte und Anlagenlisten
• Page ID: 322

Interne Linkkandidaten nach redaktioneller Prüfung:

• Kapitel 3: Stromverbrauch, lokale Erzeugung und Importkosten.
• Kapitel 5: Kommunale Liegenschaften als erster Umsetzungsraum.
• Kapitel 8: Netzbetreiber-Kommunikation und Prozessrisiken.
• Kapitel 10: Speicher, Flexibilität und steuerbare Verbrauchseinrichtungen.
• Nachweisregister.
• Rechenlogik und Tabellen.

Offene Nachweise vor Veröffentlichung:

• lokale Messpunktliste mit Marktlokation, Messlokation, Zähler, Kostenstelle und Lieferstelle,
• kommunales Liegenschaftsregister mit Objekt-ID,
• MaStR-Export mit reproduzierbarem Filter, Exportdatum, Originaldatei und Hash,
• Netzbetreiber- und Messstellenbetreiberantworten,
• lokale Lastgänge, Zählerstandsgänge und Einspeisegänge,
• Anlagen-/Asset-Tabelle mit Betreiber-, Vertrags- und Haushaltsbezug,
• Datenschutz- und Freigabestatus,
• Haushaltsstellen und Beschlussbezüge,
• redaktionelle Gegenprüfung gegen Kapitel 3, 5, 8, 10, Nachweisregister und Rechenbeispiele.