Einfluss der Datendarstellung auf Messwertkonsistenz und Abrechnungsprozesse in der Energiewirtschaft

1. Grundlegende Unterschiede zwischen binärer (binary64) und dezimaler Darstellung

In der Energiewirtschaft werden Messwerte (z. B. Stromverbrauch, Einspeisemengen, Netzlast) häufig über APIs übertragen. Die Wahl des Datenformats – insbesondere zwischen binärer Gleitkommadarstellung (binary64, IEEE 754-2008) und dezimaler Darstellung (unbegrenzter Länge) – hat direkte Auswirkungen auf die Genauigkeit, Konsistenz und regulatorische Konformität von Abrechnungsprozessen.

1.1 Binäre Gleitkommadarstellung (binary64)

• Technische Grundlage: IEEE 754-2008 (ISO 60559:2011) definiert die doppelt genaue Gleitkommazahl (64 Bit), die eine binäre Mantisse verwendet.
• Genauigkeitsprobleme:
  • Dezimalbrüche (z. B. 0,1) können nicht exakt in binärer Form dargestellt werden, was zu Rundungsfehlern führt.
  • Beispiel: 0.1 + 0.2 ergibt in binary64 nicht exakt 0.3, sondern 0.30000000000000004.
  • Folgen für die Energiewirtschaft:
    • Kumulierte Rundungsfehler bei Strommengenberechnungen (z. B. bei Viertelstundenwerten).
    • Inkonsistenzen bei Abrechnungsdaten, wenn Summen aus Einzelwerten gebildet werden.

1.2 Dezimale Darstellung (unbegrenzte Länge)

• Technische Grundlage: Dezimalzahlen werden exakt als Zeichenketten oder spezielle Dezimalformate (z. B. decimal in JSON-Schema) übertragen.
• Vorteile:
  • Keine Rundungsfehler, da Dezimalbrüche (z. B. 0,1 kWh) präzise abgebildet werden.
  • Konsistente Summenbildung, da keine binären Approximationen auftreten.
  • Bessere Nachvollziehbarkeit für regulatorische Prüfungen (z. B. nach EnWG, StromNZV, MaBiS).

2. Auswirkungen auf Messwertkonsistenz und Abrechnungsprozesse

2.1 Messwertkonsistenz

• Problem bei binary64:
  • Bei kumulierten Werten (z. B. Tagesverbrauch aus 96 Viertelstundenwerten) können sich Rundungsfehler aufsummieren, was zu Abweichungen zwischen gemessenen und berechneten Werten führt.
  • Beispiel:
    • Einzelmessung: 0,123456 kWh (binary64: 0,12345600000000001)
    • Summe über 100 Messungen: 12,3456 kWh (tatsächlich: 12,345600000000001 kWh)
    • Differenz von 0,0000000000001 kWh – scheinbar gering, aber bei Milliarden von Messwerten relevant.
• Lösung mit dezimaler Darstellung:
  • Jeder Wert wird exakt übertragen, Summen sind konsistent mit den Einzelwerten.
  • Regulatorische Anforderungen (z. B. § 21 EnWG, § 60 EEG) werden besser erfüllt, da keine unbeabsichtigten Abweichungen auftreten.

2.2 Abrechnungsprozesse und regulatorische Anforderungen

• Regulatorische Vorgaben:
  • EnWG (Energiewirtschaftsgesetz): Verlangt korrekte und nachvollziehbare Abrechnung.
  • StromNZV (Stromnetzzugangsverordnung): Fordert transparente und manipulationssichere Messwertverarbeitung.
  • MaBiS (Marktregeln für die Durchführung der Bilanzkreisabrechnung): Verlangt hohe Genauigkeit bei der Bilanzierung von Strommengen.
• Risiken bei binary64:
  • Abrechnungsdifferenzen können zu Streitigkeiten zwischen Netzbetreibern, Lieferanten und Bilanzkreisverantwortlichen führen.
  • Prüfbehörden (z. B. BNetzA) könnten Nachweise für Rundungsfehler verlangen, was zu aufwändigen Korrekturverfahren führt.
• Vorteile dezimaler Darstellung:
  • Exakte Übereinstimmung zwischen gemessenen, übertragenen und abgerechneten Werten.
  • Einfachere Auditierbarkeit, da keine binären Approximationen erklärt werden müssen.
  • Reduzierter Aufwand für Korrekturprozesse (z. B. nach § 12 StromNZV).

3. Empfehlungen für die API-Gestaltung in der Energiewirtschaft

3.1 Technische Umsetzung

• Verwendung von decimal statt double/binary64:
  • In OpenAPI/Swagger-Spezifikationen sollte für Messwerte, Abrechnungsdaten und Bilanzkreisgrößen das Format decimal (unbegrenzte Länge) verwendet werden.
  • Beispiel:

    components:
      schemas:
        Verbrauchswert:
          type: number
          format: decimal
          example: 1234.56789
    

• Vermeidung von binären Gleitkommazahlen für finanzielle und regulatorische Daten:
  • Strommengen, Preise, Abrechnungswerte sollten niemals als binary64 übertragen werden.
  • Ausnahme: Technische Parameter (z. B. Spannung, Frequenz), bei denen Rundungsfehler tolerierbar sind.

3.2 Regulatorische Absicherung

• Dokumentation der Datenformate:
  • In API-Dokumentationen muss klar angegeben werden, ob binary64 oder decimal verwendet wird.
  • Begründung für die Wahl sollte regulatorische Anforderungen (z. B. MaBiS, EnWG) berücksichtigen.
• Testverfahren für Konsistenz:
  • Automatisierte Prüfungen sollten sicherstellen, dass Summen aus Einzelwerten exakt mit den aggregierten Werten übereinstimmen.
  • Beispiel-Testfall:
    • 96 Viertelstundenwerte à 0,123456 kWh → Summe muss exakt 11,851776 kWh ergeben (nicht 11,851776000000001 kWh).

3.3 Interoperabilität und Standardisierung

• Einheitliche Formate in der Branche:
  • Empfehlung: Nutzung von dezimalen Formaten in standardisierten APIs (z. B. nach BDEW, EDI@Energy, Gaia-X).
  • Vermeidung von proprietären Lösungen, die Rundungsfehler begünstigen.
• Kompatibilität mit bestehenden Systemen:
  • Falls legacy-Systeme nur binary64 unterstützen, sollten Konvertierungsregeln definiert werden, um Datenverluste zu minimieren.

4. Fazit

Die Wahl zwischen binärer (binary64) und dezimaler Darstellung hat erhebliche Auswirkungen auf die Genauigkeit, Konsistenz und regulatorische Konformität von Messwerten und Abrechnungsprozessen in der Energiewirtschaft.

Empfehlung: Für alle abrechnungsrelevanten Daten (Strommengen, Preise, Bilanzkreiswerte) sollte ausschließlich die dezimale Darstellung verwendet werden, um Rundungsfehler zu vermeiden und regulatorische Anforderungen zuverlässig zu erfüllen. Binäre Gleitkommazahlen (binary64) sind nur für technische Parameter mit tolerierbaren Ungenauigkeiten geeignet.