Wenn wir davon ausgehen, dass hinter dem Hausanschluss vermehrt eine Smart-home-Steuerung installiert ist, misst der privat eingebaute Summenzähler genau den gleichen Strom wie der Smartmeter des Verteilnetzbetreibers. Dies bedeutet, dass wir eine doppelte Messinfrastruktur sowie Datenströme ohne Nutzen haben. Deshalb wurden für eine effiziente Bereitstellung der benötigten Daten die folgenden zwei Verbesserungsansätze in der Praxis getestet und überprüft: Um Doppelspurigkeiten zu eliminieren und eine effiziente Nutzung der Messdaten zu ermöglichen, haben elektroplan Buchs & Grossen AG sowie Smart Energy Link AG (SEL) und BKW in einem Projekt zwei Optimierungsvorschläge erarbeitet. In der Folge werden diese kurz beschrieben:
- Fall 1 (smarter Ansatz, in untenstehender Grafik grün dargestellt): Der Smartmeter des VNB wird weggelassen: Dadurch liefert die Gebäudesteuerung dem VNB die für Billing und Reporting nötigen Messdaten und der VNB-Smartmeter erübrigt sich. Dazu werden zertifizierte Zähler eingesetzt, welche nicht Eigentum des VNB sind. Dieser Ansatz müsste in der Stromversorgungsverordnung legalisiert werden.
- Fall 2 (StromVV-Ansatz, in untenstehender Grafik blau dargestellt). In diesem Fall erübrigt sich der Summenzähler der Smarthome-Steuerung und wird somit weggelassen.Der VNB-Smartmeter liefert der Gebäudesteuerung Messdaten, und der Summenzähler der Smarthome Steuerung erübrigt sich.
Bereits heute im Gesetz verankert müsste dieser Ansatz weiter standardisiert werden, sodass er auch in der Praxis tatsächlich umgesetzt werden kann und wird.
Die beiden Konstellationen erlauben verschiedene Daten-Transportwege zwischen den privaten Systemen und den Systemen des VNB, die für beide Fälle in der folgenden Abbildung zusammengefasst sind. Die im Projekt umgesetzten Varianten sind mit Fall 1/Fall 2 markiert.
Private Datenlieferung (Fall 1)
Der Transportweg 1a) wurde umgesetzt: Der SEL-Zähler (EMU Professional) liefert Messdaten via Gebäudesteuerung und Cloud an die IoT Azure Hub Infrastruktur der BKW (Active Power in beide Richtungen – OBIS 1.29.0 und 2.29.0).
In diesem Zusammenhang ist wichtig zu erwähnen, dass die technischen Herausforderungen gelöst und in einen ökonomisch sinnvollen Rahmen gestellt werden konnten:
- Die technische Kommunikation erfolgt über Standardmechanismen: Hier werden Technologien aus der Microsoft Azure Welt eingesetzt. In unserem Fall liefert die SEL-Cloud Messdaten verschlüsselt via MQTT an den Microsoft Azure IoT Hub. Die beiden Messungen (BKW und SEL) weisen eine hohe Korrelation auf.Eine weitere Effizienzsteigerung bringen die SmartGridready-Deklarationen der Schnittstelle zwischen Smarthome-Cloud und Verteilnetzbetreiber, die eine Reduktion der Entwicklungskosten bewirken.
- Harte Sicherheit oder weiche Plausibilisierung: A priori besteht zwischen Smarthome-Providern und Verteilnetzbetreibern die gleiche «Vertrauenssituation» wie im Internet (Webshop, Telebanking). Als Erstes drängt sich eine bewährte Sicherheits-Umsetzung wie folgt auf: Die Messdaten des Zählers werden signiert an den Verteilnetzbetreiber übermittelt. Der Missbrauch bezüglich Zählerkonfiguration wird durch Signaturen unterbunden. Damit verbunden sind aber erhebliche Kosten für die Erstellung und den Betrieb einer Sicherheitsumgebung mit PKI (Public-Key-Infrastruktur). ❭
- Alternative: Die Sicherheit wird auf dem obenerwähnten minimalen Standard belassen. Allerdings werden die beim VNB eintreffenden Messdaten «plausibilisiert». Dies wird als Sammelbegriff für eine ganze Gruppe von Services verwendet, die ebenfalls standardgemäss aus der Microsoft Azure Cloud bezogen werden. Konkret sprechen wir hier von Kombination aus klassischer Mathematik-Statistik, Rule Based Engine, Anomaly Detection sowie Big-Data-Methoden. Die Plausibilisierung ist ökonomisch sehr attraktiv und weist aus Erfahrung bloss ein paar wenige Fehlerprozentpunkte auf – also ein massiv günstigeres Kosten-Nutzen-Verhältnis als harte Sicherheits-Vorkehrungen.
Plausibilisierung
Liegt bei einer Plausibilisierung nun eine Art Security Vulnerabilität vor? Die Risiken sehen folgendermassen aus: Die Datenstrecke zwischen Home Energy Cloud und VNB wird verschlüsselt und bietet keine grössere Angriffsfläche, dagegen kann die Datenstrecke zwischen Zähler und Home Energy Cloud an verschiedenen Stellen «angegriffen» werden:
- Daten werden verändert an den Verteilnetzbetreiber geliefert: Dies wird zu einem sehr hohen Prozentsatz durch die Plausibilisierung detektiert.
- Daten werden «abgezogen» und im Sinne des Datenschutzes missbräuchlich verwendet: Diese Gefahr besteht schon heute und wird durch ein klares Identity- und Access-Management verhindert.
Der Fall 1 bietet weitere Vorteile, zum Beispiel, dass die Datendichte wie im Datenschutz gefordert, auf das Nötige reduziert werden kann.
Verwendung Kundenschnittstelle (Fall 2)
Umgesetzt wurden Transportweg 2d) sowie ansatzweise 2a). Der BKW Smartmeter liefert Messwerte via RS485 zuhanden Gebäudesteuerung. Hierzu wurde eine Kundenschnittstelle simuliert. Der Smartmeter (L+G E 570) wurde so konfiguriert, dass die RS485-Schnittstelle Messwerte pusht, um die Machbarkeit einer derartigen Konfiguration aufzuzeigen. In Zukunft sollte dies über die vom Gesetz vorgesehene Kundenschnittstelle (in der Abbildung KS2) erfolgen. Aufgrund fehlender detaillierter Standardisierung bezüglich KS2 resp. der vergleichsweise hohen Kosten individueller Programmierung wurde Fall 2 abgebrochen, und stattdessen wurden (Schnittstellen-) Profile erarbeitet. Die Profile wurden bei SmartGridready (vgl. auch oben) eingereicht. Nach erfolgreicher Prüfung wird SmartGridready diese Profile implementationsnah als Unified Modeling Language (UML) zur Verfügung stellen, was weitere Kosteneinsparungen ergibt.
Fazit
Aus den Analysen ergibt sich folgender rechtlicher und «technischer» Handlungsbedarf: Für Fall 1 postuliert das Projektteam die entsprechende Anpassung der Stromversorgungsverordnung. Im Fall 2 schlägt das Projektteam eine engere Standardisierung der Kundenschnittstelle vor.