LoRaWAN-Netzbetrieb Archives - items GmbH & Co. KG

Praxisbericht: LoRaWAN in der Netzleitstelle

Smart Grid: Mit LoRaWAN in der Netzleitstelle

LoRaWAN in der Netzleistelle zur Realisierung eines intelligenten Energieversorgungsnetzes ist längst kein abstraktes Thema in der Branche mehr. Immer mehr EVUs begeben sich auf den Weg, ihre neugewonnenen Informationen in die jeweiligen Fachsysteme zu integrieren. Neben der Abrechnung von LoRaWAN-Zählern stellt die Netzleitwarte eines Stadtwerks ein präferiertes System da. Hierbei soll LoRaWAN als Übertragungstechnik dazu dienen, den Transformationsprozess des Energieversorgungsnetzes hin zu einem Smart Grid zu unterstützen.

Die Netzleitstelle als Herzstück zur Überwachung und Steuerung des Energieversorgungsnetzes nimmt dabei eine zentrale Rolle ein. Die erhobenen Daten aus dem LoRaWAN-Netz werden dem Mitarbeiter in der Leitwarte für eine bessere Entscheidungsgrundlage zur Verfügung gestellt. Die Ableitung von Maßnahmen soll so besser und einfacher getroffen werden können. Doch es stellt sich grundsätzlich die Frage, wie eine Integration von Messwerten aus dem LoRaWAN-Netz in die Netzleitstelle erfolgt und welche Daten dort überhaupt visualisiert werden sollten. Da viele vor Projekten rund um das Thema Netzleitwarte auf Grund der hohen Komplexität oder Sicherheitsbedenken zurückscheuen, wollen wir einen Blick darauf werfen, welche Fragestellungen zu klären sind und wie ein solches Projekt umgesetzt werden kann. Ausgangspunkt sind jedoch die technischen Voraussetzungen, weswegen wir zuerst einen Blick auf die Grundlagen der Fernwirktechnik und die notwendige IT-Architektur werfen:

Fernwirktechnik: Was sind die Grundlagen?

In der Vergangenheit und auch noch heute erfolgt die Anbindung von Assets in die Netzleitwarte oft über klassische Fernwirktechnik. Dabei stellt die Fernwirktechnik einen Teil der Netzleittechnik dar, der die Messungs-, Steuerungs- und Regelungstechnik umfasst. In der Fernwirktechnik ist zwischen der Überwachungs- und Steuerungsrichtung zu unterscheiden. Diese sind abhängig vom Blickwinkel des Betrachters, sprich dem Mitarbeiter in der Netzleitwarte. Aus Blickrichtung des Betrachters spricht man von der Steuerungsrichtung. Aus der Perspektive zum Betrachter hin, hingegen von der Übertragungsrichtung.

Die Fernwirktechnik besteht im Allgemeinen aus einem zu überwachenden Objekt, das mittels eines Fühlers überwacht wird. Der Fühler greift physikalische Größen wie z. B. den Druck oder Temperaturwert des Assets ab und wandelt den analogen Messwert mittels eines Umformers in einen digitalen Messwert um. Standardschnittstellen sind hier z. B die 0-20 mA- oder 4-20 mA-Schnittstelle. Über einen Verstärker erfolgt die Übertragung des digitalen Messwerts zu einem zweiten Umformer, der den digitalen Messwert zurück in einen analogen Messwert übersetzt und der Netzleitstelle zur Verfügung stellt. Der Mitarbeiter kann sich dann die Information des Objekts in der Netzleitstelle anzeigen lassen und ggf. Steuerungsbefehle ausgeben, sofern das Objekt über eine entsprechende Steuerungseinheit verfügt.

Grundlagen der Fernwirktechnik

Hier stellt sich nun die Frage, wie eine Integration von LoRaWAN in der Netzleitstelle erfolgen kann und wie auf den bereits bestehenden Erfahrungen im Bereich der Fernwirktechnik aufgesetzt werden kann. Hierzu werfen wir einen ersten Blick auf die notwendige IT-Architektur:

IT-Architektur: LoRaWAN in der Netzleistelle

Bei der Integration eines Objekts mittels LoRaWAN in die Netzleitwarte ist wie auch in der Fernwirktechnik ein geeigneter Fühler auszuwählen. Der LoRaWAN-Sensor stellt dabei den Fühler dar. Dieser wandelt die analogen Messwerte in digitale Messwerte um. Alternativ können auch bereits bestehende digitale Messwerte abgegriffen werden und über eine LoRaWAN-Bridge in das „LoRaWAN-Format“ übersetzt werden, wie dies in der folgenden Abbildung dargestellt ist.

Der LoRaWAN-Sensor als Fühler ist zur Übertragung der Messwerte in das LoRaWAN-Netz eingebunden. Dieses übernimmt die Rolle des Verstärkers zum Transport der Messwerte und besteht aus dem LoRaWAN-Gateway und dem LoRaWAN-Netzwerk-Server (LNS). Die Informationen werden an den Data-Hub, die IoT-Plattform, übertragen. Dort findet die Entschlüsselung der LoRaWAN-Messwerte statt. Über eine integrierte Schnittstelle im Data-Hub erfolgt dann eine Übersetzung der Messwerte in das IEC-104-Protokoll. Dabei handelt es sich um ein standardisiertes Protokoll, das in der Fernwirktechnik eingesetzt wird und von der Netzleitstelle verarbeitet werden kann. Das Protokoll gibt bestimmte Arten bzw. Typen von Messwerten vor, die übertragen werden können. In diesem Beispiel sind dies die Typen 1,2 und 13.

Bei der Schnittstelle im Data-Hub handelt es sich um einen IEC-104-Slave, der mit einem IEC-104-Master aus der Netzleitwarte verbunden ist, da Netzleitwarten nach dem Master-Slave-Prinzip arbeiten. Hierfür muss eine Verbindung zwischen dem Master und dem Slave (Master-Slave-Prinzip) hergestellt werden. In unserem Beispiel steht der Data-Hub mit dem 104-Slave im kommunalen Rechenzentrum der items GmbH und der Master im Rechenzentrum des Kunden. Zur Sicherstellung einer sicheren Verbindung ist ein VPN-Tunnel zwischen Master und Slave installiert. Eine Anpassung der Firewallregeln ist hierfür notwendig.

Nachdem eine Verbindung zwischen Master und Slave hergestellt ist, müssen beide aufeinander abgestimmt werden. Nach erfolgter Konfiguration ist nun eine Einrichtung von Sensoren im Data-Hub-LoRaWAN möglich. Zur Übertragung der Messwerte sind die Sensoren mit dem IEC-104-Slave im Data-Hub zu verknüpfen. Die Netzleitwarte kann sich dann über den IEC-104-Master die Daten über das Pullprinzip abholen. Zuletzt erfolgt eine Weiterleitung der Messwerte über den Master per LAN-Verbindung in die Verbunds- bzw. Netzleitstelle.

IT-Architektur

Anwendungsfälle: Welche gehören in die Netzleitstelle?

Auf dem ersten Blick ist man schnell dazu verleitet, möglichst alle Informationen in der Netzleitwarte zu visualisieren. Von Strom- und Spannungsmessungen an Trafostationen und KVS-Schränken über jegliche Assets im Bereich der Gas- und Wasserversorgung wie in der Fernwärme. Bevor dies jedoch erfolgt, sollte zuerst eine Analyse und Grundsatzentscheidung getroffen werden, welche Messwerte in die Netzleitwarte gehören und welchen Mehrwert diese liefern sollen. Im Allgemeinen ist die Frage zu beantworten: Handelt es sich um Messwerte, die für ein Live-Monitoring notwendig sind oder eher um Messreihen zur Planung und Optimierung des Energieversorgungsnetzes?
Viele Messwerte werden oft nur zu Planungs- oder strategischen Optimierungszwecken benötigt, weswegen eine Integration nicht erforderlich ist. Im Fokus sollten daher Messwerte stehen, die dem Live-Monitoring dienen und die Entscheidungsfähigkeit des Mitarbeiters unterstützen. Schalthandlungen sollten dabei nicht umgesetzt werden, da die Latenzzeit und Zuverlässigkeit von LoRaWAN zu gering ist, um eine sachgerechte Umsetzung von Steuerungsbefehlen zu gewährleisten.

In der Praxis handelt es sich um Anwendungsfälle, die eher Entscheidungen in der Netzleitwarte betreffen und die die Handlungsfähigkeit der Mitarbeiter beschleunigen, deren Ausfall aber nicht den Betrieb des Energieversorgungsnetzes gefährdet. Ein klassisches Beispiel stellen Schleppzeiger dar. Wird ein Schleppzeiger mittels eines LoRaWAN-Sensors überwacht und ausgelöst, erhält der Mitarbeiter die Information sofort in der Netzleitwarte. Da der Standort der Fehlermeldung bekannt ist, kann der Monteur gezielt den Fehlerort ansteuern. Die Störung kann deutlich schneller behoben werden, da nicht ggf. jede Ortsnetzstation einzeln abgefahren werden muss. Das Q-Element kann so deutlich gesteigert werden. Sollte der LoRaWAN-Sensor ausfallen, stellt dies aber keine Gefährdung des Betriebs dar, weil zur Not wie früher jede Ortsnetzstation einzeln angefahren werden kann.

Daher haben sich in der Praxis verschiedene Anwendungsfälle über die einzelnen Sparten durchgesetzt. Hierzu zählt z. B. neben der Überwachung von Schleppzeigern, das Monitoren von Kurzschlussanzeigern, die Überwachung von Sicherheitsabsperrventilen (SAV) bei Gasdruckregelstationen, das Monitoren von Fernwärmeschlechtpunkten oder die Strom- und Spannungsüberwachung netzrelevanter Trafostationen.

ISO 27001: Ist LoRaWAN in der Netzleitstelle erlaubt?

Da es sich bei der Netzleitstelle um einen Teil der kritischen Infrastruktur handelt, ist die Sicherheit ein wesentliches Kriterium. Hierfür hält jeder Netzbetreiber ein eigenes Informationssicherheitskonzept nach der ISO 27001 vor. Da mit der Integration von LoRaWAN in der Netzleitstelle aktiv in das System eingegriffen wird, sind immer auch die Auswirkungen auf das Sicherheitskonzept zu berücksichtigen.

Ob eine Anpassung des Informationssicherheitskonzepts nach ISO 27001 notwendig ist, muss immer im Einzelfall geprüft werden. Eine Pauschalaussage ist an dieser Stelle nicht möglich, da auch der Scope des Konzepts entscheidend ist. In vielen Fällen wird der Scope erst berührt, wenn über LoRaWAN auch Schalthandlungen realisiert werden würden. Dies ist aber in den meisten Fällen nicht der Fall und auf Grund der technischen Eigenschaften von LoRaWAN selten ratsam.

Da die LoRaWAN-Messwerte eher den Entscheidungsprozess des Mitarbeiters fördern, im Falle einer Nichtverfügbarkeit der Daten aber nicht den Netzbetrieb gefährden, ist eine Anpassung des Konzepts meist nicht notwendig. Allerdings haben manche Netzbetreiber ihren Scope soweit gefasst, dass schon die bloße Existenz der Information ausreicht, die Entscheidung eines Mitarbeiters zu verändern, sodass dies auch im Informationssicherheitskonzept zu berücksichtigen ist. In diesem Fall ist eine Risikobetrachtung und -bewertung durchzuführen. Zusätzliche Sicherheitsmaßnahmen könnten im Einzelfall die Folge sein, die einen Einsatz von LoRaWAN in der Netzleitstelle nicht verhindern.

Projektumsetzung: Worauf kommt es an?

Bei Projekten rund um die Netzleitwarte haben viele Projektmanager und Beteiligte oft Bedenken, was die Umsetzung angeht. Zum einen besteht eine hohe Komplexität hinsichtlich der Integration der Projektbeteiligten, da eine Vielzahl von Mitarbeitern mit unterschiedlichem Know-how notwendig sind. Zum anderen müssen die Fragen hinsichtlich der IT-Sicherheit ausreichend beantwortet werden, um die Fachabteilung erfolgreich einzubinden. Hinzu kommt die Problematik des unterschiedlichen inhaltlichen Verständnisses der Beteiligten. Hinzu können Kommunikationsprobleme kommen, die aus einem unterschiedlichen Wording entstehen. So können z. B. Mitarbeiter aus der Fernwirktechnik unter dem Begriff Master-Slave etwas komplett anderes verstehen als die Mitarbeiter aus der IT, welche die Firewallregeln anpassen. Aus diesem Grund ist die Grundvoraussetzung, dass die notwendigen Wissenträger eingebunden sind und in diesem Fall bereits ein LoRaWAN-Netz besteht sowie der Data-Hub bereits im Einsatz ist.
Zur Integration von LoRaWAN in die Netzleitstelle sollte daher im ersten Schritt der IEC-104-Slave im Data-Hub installiert und konfiguriert werden. Im Anschluss erfolgt die Installation des VPN-Tunnels. Die Verbindung zwischen dem IEC-104-Slave im Data-Hub und dem IEC-104-Master der Netzleitstelle sollte dann über ein Ping-Signal getestet werden, um die Funktionsfähigkeit des VPN-Tunnels zu gewährleisten.

Ist der VPN-Tunnel einsatzfähig, kann die Konfiguration des IEC-104-Slave und -Master erfolgen. Hier bietet es sich an, direkt mit einem Testsensor die Konfiguration auszuprobieren. Ist die Konfiguration abgeschlossen, kann die Verbindung vom Data-Hub zur Netzleitstelle für weitere Sensoren genutzt werden. Die Umsetzung der Anwendungsfälle kann somit starten.

In der Praxis wird für ein Projekt dieser Art ein Zeitraum von 1 bis 3 Monaten benötigt. Die Zeitspanne ist abhängig vom IoT-Wissen des Kunden, der Anzahl der eingebundenen Dienstleister und der Größe des Personenkreises. Gerade bei einer hohen Dienstleisterdichte und vielen Projektbeteiligten besteht ein hoher Abstimmungsbedarf, der zu einer längeren Projektumsetzung führt. Hierbei stellten in laufenden Projekten eine ausreichende Kommunikation, die Einführung eines einheitlichen Wordings, das alle Projektbeteiligten verstehen, und die Anpassung der Firewallregeln, wenn mehrere Dienstleister integriert waren, die größten Herausforderungen dar. Je nach Komplexität liegt ein solches Projekt bei zwischen 10 bis 20 Personentagen. Zusätzliche Anpassungen in der Netzleitwarte durch den Hersteller der Netzleitwartensoftware und Aufwände für eine mögliche Anpassung des ISMS nach ISO 27001 sind in dieser Kalkulation nicht enthalten.

Projektstruktur zur Integration von LoRaWAN

Fazit: LoRaWAN in der Netzleitstelle

Die Integration von LoRaWAN in der Netzleitstelle stellt aus heutiger Sicht kein großes Problem mehr da. Die Technik ist mittlerweile so weit, dass eine Integration problemlos möglich ist. Die Komplexität und Aufwände sind nicht höher als bei anderen, heute üblichen IT-Projekten. Durch die Integration von Messwerten in der Netzleitwarte wird den Mitarbeitern die Möglichkeit gegeben, die Informationen aus dem LoRaWAN-Netz direkt im eigenen Fachsystem zu nutzen. Ein Zugriff auf den Data-Hub und somit ein Medienbruch für den Mitarbeiter ist somit nicht mehr nötig.
Durch die Verbesserung der Prozesseffizienz im Netzbetrieb ist von einer schnellen Amortisation der Kosten auszugehen. Durch die Steigerung des Q-Elements, z. B. durch das Überwachen von Schleppzeigern, und einer schnelleren Störungsbehebung können finanzielle Mehrwerte schnell gehoben werden. Hinzu kommt eine generelle Zeitersparnis für die eigenen Mitarbeiter, da die Anzahl des Personals bedingt durch den demographischen Wandel stetig abnimmt.

Zur Umsetzung eines sog. Smart Grids wird es jedoch nicht ausreichen, nun sämtliche Anwendungsfälle auf LoRaWAN zu realisieren und in die Netzleitwarte zu integrieren. LoRaWAN stellt in diesem Kontext nur ein zusätzliches Werkzeug dar, das die Transformation des Energieversorgungsnetzes unterstützt. Vielmehr ist in der Zukunft von einem Technologie-Mix auszugehen, bei dem sowohl kabelgebundene Lösung per Glasfaser, als auch Funklösungen wie LoRaWAN, 450 MHz oder NB-IoT zum Einsatz kommen.

Bei Fragen zu diesem Blogbeitrag meldet euch gerne. Wenn euch der Artikel gefallen hat, abonniert gerne unseren Blog.

Grid Insight: LPWAN – das LoRaWAN-Netzvermessungstool

Grid Insight: LPWAN – das LoRaWAN-Netz auf einem Blick

Wie gut ist meine LoRaWAN-Netzabdeckung wirklich? Gibt es in meiner Trafostation Empfang? Wo existieren aktuell noch Funklöcher und wie gut ist der bereits erschlossene Gatewaystandort? Vor diesen Fragen und noch weiteren Herausforderungen steht heute jedes Stadtwerk, das sich mit dem Betrieb eines LoRaWAN-Netzes beschäftigt. Im Kern steht für jedes Stadtwerk als LoRaWAN-Netzbetreiber eine Frage im Raum: Wie gut ist die Netzabdeckung in meiner Stadt wirklich? Antwort auf diese Frage gibt die neue Software der items Grid Insight: LPWAN. Bei dieser Lösung handelt es sich um eine Software, die bei der Analyse, Umsetzung und Planung des eigenen LoRaWAN-Netzes unterstützt. Bereits in der Testphase der Entwicklung von Grid Insight: LPWAN waren die Stadtwerke Osnabrück, Solingen und Bielefeld eingebunden. Dabei war ein Kernziel der Lösung, dem Anwender eine Heatmap seiner Stadt bereitzustellen, welche die Netzabdeckung, aber auch Funklöcher darstellt. Auf Basis dieser Informationen kann das Stadtwerk erkennen, an welchen Stellen ein Netzausbau erforderlich oder ein Gatewaystandort zu optimieren ist. Doch wie funktioniert die Software eigentlich und wie werden die Messwerte zur Netzabdeckung erhoben? Das alles wollen wir euch in diesem Blogbeitrag vorstellen.

Ausgangspunkt Fieldtester – Messwerte unkompliziert erheben

Der erfahrene LoRaWAN-Anwender wird das Vermessen von LoRaWAN-Netzen als etwas sehr Aufwendiges einstufen, bei dem er mit einem Fieldtester durch die Stadt fährt und in bestimmten Abständen manuell ein Testsignal zur Bestimmung der Empfangsstärke verschickt. Oft kommt hier der Adeunis Fieldtester zum Einsatz. Das Verfahren ist auf den ersten Blick einfach und simpel und für einen Stichprobentest sicher hilfreich, jedoch für die Vorbereitung eines LoRaWAN-Rollouts nicht geeignet. Auch die Dokumentation der Messergebnisse bleibt auf der Strecke, da der Anwender lediglich eine Information über die Empfangsstärke auf dem Display des Fieldtesters erhält. Eine Dokumentation erfolgt in der Regel nicht.

Um ein flächendeckendes Bild von der Netzabdeckung zu erhalten, Bedarf es einer automatisierten Netzvermessung, die sowohl die Empfangsstärke, aber auch die Funklöcher erfasst und ein System zur Dokumentation bereitstellt. Aus diesem Grund hat die items neben der Software Grid Insight: LPWAN einen speziellen Fieldtester entwickelt, der z. B. in die Fahrzeuge der Monteure oder Busse eingebaut werden kann und permanent das Netz vermisst. Alternativ können die Fieldtester auch dem zuständigen Messdienstleister im Rahmen der jährlichen Turnusablesung mitgegeben werden. Durch die eingebaute Intelligenz des Fieldtesters erkennt dieser im Zuge einer Testmessung, ob das Datenpaket über den LoRaWAN-Netzwerk-Server (LNS) verarbeitet wurde oder ob ein Funkloch vorliegt. Eine Weiterleitung der Datenpakete zur Empfangsmessung erfolgt über den LNS an die angebundene IoT-Plattform. Die Bereitstellung der Informationen erfolgt über eine MQTT-Schnittstelle. Im Anschluss erfolgt die Visualisierung der Daten.

Mehrwerte Grid Insight LPWAN

Grid Insight: LPWAN – Herzstück Heatmap

Bereits im Rahmen der Messung der Netzabdeckung ist über eine Live-Funktion in Grid Insight: LPWAN ersichtlich, wo sich die Fieldtester befinden und die Erhebung von aktuellen Messwerten erfolgt. In einem Data-Lake ist eine Verschneidung der verschiedenen Messreihen über einen größeren Zeitraum möglich. Hierbei ist eine Auswahl der jeweiligen Spreading-Faktoren und Gateways möglich. Das Ergebnis ist eine Heatmap, die dem Anwender Auskunft über die Empfangsqualität gibt. Eine grüne Abdeckung bedeutet in diesem Fall eine gute Abdeckung. Eine rote Abdeckung hingegen weist auf eine Abdeckung hin, jedoch ist mit einem höheren Datenverlust zu rechnen, da ein hoher Spreading-Faktor nötig ist. Die Visualisierung der Funklöcher erfolgt als rotes X. So ist für den Nutzer ersichtlich, an welchen Stellen bereits eine Messung erfolgt, aber keine Netzabdeckung vorhanden ist.

Beispiel einer visualierten Messreihe

Für das Stadtwerk bietet die Heatmap einen operativen Mehrwert. Auf der einen Seite kann schnell Auskunft über die Netzabdeckung sowie -qualität in Form des Spreading-Faktors und RSSI-Wertes gegeben werden, um eigene Projekte umzusetzen. Auf der anderen Seite kann die Heatmap die Auskunftsfunktion gegenüber Dritten erfüllen. Viele Stadtwerke sind mittlerweile damit beschäftigt, ihr LoRaWAN-Netz Dritten bereitzustellen. Neben der Definition von technischen Mindestanforderungen und dem Aufbau von Organisationsprozessen stellt eine Auskunft über die Netzabdeckung ein wesentliches Kriterium dar. Grid Insight: LPWAN bietet somit eine wichtige Funktionserfüllung auf dem Weg zum IoT-Dienstleister. Jedoch ist nicht nur die Analyse der Netzabdeckung möglich. Auch eine Bewertung der Gatewaystandorte kann durch den Nutzer erfolgen.

Grid Insight: LPWAN – Bewertung von Gatewaystandorten

Das zentrale Asset zur Sicherstellung der Netzabdeckung stellt das LoRaWAN-Gateway dar. Aus diesem Grund ist die Bewertung von Gatewaystandorten für das Stadtwerk relevant. Vor allem dann, wenn Standorte von Dritten erschlossen wurden, für die eine hohe jährliche Nutzungsgebühr zu zahlen ist. Aus diesem Grund ist bei der Verschneidung von Messwerten zu einer Heatmap eine Filterfunktion auf Gatewayebene möglich. Eine Analyse und Bewertung des Beitrags der Gesamtnetzabdeckung einzelner Gateways ist so ersichtlich.

Durch die zusätzliche Information in einzelnen Messreihen, mit welchen Spreading-Faktoren Datenpakete die einzelnen Gateways erreichen, ist außerdem eine Senkung des Energieverbrauchs der Sensoren möglich. Mittels Installation eines zusätzlichen Gateways oder der Verbesserung des Gatewaystandortes kann der Spreading-Faktor der Sensoren und somit der Energieverbrauch gesenkt werden. Grid Insight: LPWAN unterstützt damit aktiv den Netzausbau und die Erschließung geeigneter Gatewaystandorte. Zur Verbesserung der Planung ist mit der zweiten Version in den nächsten Monaten auch eine Simulationsfunktion geplant, um die Auswirkungen einer Änderung von Gatewaystandorten direkt nachvollziehen zu können.

Auswertung von Gatewaystandorten

Grid Insight: LPWAN in der Praxis

Durch die agile Softwareentwicklung in Zusammenarbeit mit dem Kunden konnten in den ersten Monaten bereits umfangreiche Testerfahrungen gesammelt werden. Bereits in der Testphase haben sich die Stadtwerke Osnabrück dazu entschieden Grid Insight: LPWAN langfristig zu testen. „Grid Insight: LPWAN bietet uns zusätzliche Transparenz und Qualität in unserem LoRaWAN-Netz. Als Entscheidungshilfe für die weitere Netzverdichtung unterstützt Grid Insight: LPWAN unsere Planung für den weiteren Rollout in der Stadt Osnabrück. Unsere Projekte zur Überwachung von Transformatoren oder Gasdruckregelstationen erhalten so einen zusätzlichen Schub. Aus diesem Grund haben wir uns bereits frühzeitig dazu entscheiden, Grid Insight: LPWAN auch über die Testphase hinaus längerfristig bei uns einzusetzen“, so Ingo Lemme, verantwortlich für den Bereich IoT bei der SWO Netz.

Bei anderen Projekten diente Grid Insight: LPWAN hingegen als Informationshilfe für die Identifizierung von Funklöchern auf Grund schwieriger topologischer Eigenschaften. Ebenso unterstützt die Software bei der Indoor-Fähigkeit des LoRaWAN-Netzes im Rahmen der jährlichen Turnusablesung des Messdienstleisters. Die erste verfügbare Version bot in allen Projekten einen erheblichen Mehrwert. Die Entwicklung von Grid Insight: LPWAN ist aber mit der ersten verfügbaren Version im Mai nicht abgeschlossen. Vielmehr soll auf Basis der Zusammenarbeit mit den Kunden an weiteren Modulen gearbeitet werden. Neben der Implementierung kleinerer Features steht das Thema Netzsimulation auf Basis der vermessenen Netzabdeckung als nächster Schritt an. „Die items hat gemäß ihren strategischen Leitlinien den Anspruch, eine Plattform für Kunden, Produkte und Services zu sein. Diesem Anspruch sind wir mit der Produktentwicklung von Grid Insight: LPWAN in allen Belangen gerecht geworden. Wir haben mehrere Kunden in die Produktentwicklung einbezogen, haben gemeinsam ein standardisiertes Produkt entwickelt, das exakt auf die Bedürfnisse unserer Kunden zielt und stellen die Services für den Betrieb der Lösung bereit. Das Ergebnis ist eine hervorragende Lösung für den Aufbau und die Optimierung von LoRaWAN-Infrastrukturen“, so Ludger Hemker Geschäftsführer der items GmbH.

Grid Insight: LPWAN Projekteinführung

Die Einführung von Grid Insight: LPWAN kann mit geringem Zeitaufwand erfolgen, da die Software als SaaS-Lösung durch die items bereitgestellt wird. Voraussetzungen sind die Fieldtester der items sowie eine Anbindung über eine MQTT-Schnittstelle an die IoT-Plattform. Die Fieldtester sind über die items im Kauf- oder Mietmodell beziehbar. Nach einer zweistündigen Schulung ist eine sofortige Nutzung möglich. In der Regel dauert der gesamte Prozess nicht länger als zwei Wochen. Auf Stadtwerke, welche die IoT-Plattform niota nutzen, warten außerdem spezielle Zusatzfunktionen, was die Integration von Sensorik betrifft. Eine Anbindung ist aber an jede IoT-Plattform über MQTT möglich. Der Bezug der Software Grid Insight: LPWAN ist ab sofort möglich. Bei Interesse sprecht uns gerne an oder abonniert unseren Blog, wenn euch der Artikel gefallen hat! Mehr Informationen zu Grid Insight LPWAN findet Ihr hier

LoRaWAN-Geschäftsmodell: Die Möglichkeiten im Überblick

Trendentwicklung: Von der Prozessoptimierung zum LoRaWAN-Geschäftsmodell

Die Technologie LoRaWAN ist in der Energieversorgungsbranche längst kein neues Thema mehr. Fast jedes Stadtwerk befindet sich entweder im Aufbau eines LoRaWAN-Netzes oder in der Betriebsphase. Die ersten Schritte in den meisten Prozessen stellen interne Projekte zur Prozessoptimierung vor allem in Energieinfrastrukturen, wie z. B. zu Überwachung von Ortnestztrafostationen, dar. Mittlerweile steht jedoch eine Vielzahl von Projekten vor dem nächsten Schritt des Rollouts und der Öffnung für Dritte. Es heißt somit für viele EVUs, ein LoRaWAN-Geschäftsmodell zu finden.

In diesem Zug ergeben sich für das EVU ganz neue Fragen. Wer darf das Netz eigentlich nutzen? Welche Dienstleistungstiefe und was soll dem Kunden angeboten werden? Hinzu kommt die Herausforderung, ein sinnvolles Preismodell zu definieren. Die Fragestellungen und Herausforderungen für die EVUs bei der Entwicklung eines LoRaWAN-Geschäftsmodells sind somit recht ähnlich. Aus diesem Grund soll der vorliegende Beitrag eine erste Umsetzungshilfe zur Orientierung bieten, wie, welche drei wesentlichen Schritte bei der Umsetzung des LoRaWAN-Geschäftsmodells zu beachten sind.

Schritt 1: Positionierung am Markt bestimmen

Ein erster wesentlicher Schritt für das EVU ist die Definition der eigenen Rolle am Markt und der Festlegung, mit welcher Dienstleistungstiefe es gegenüber dem Kunden auftreten möchte. Dies hängt maßgeblich von den Ressourcen und dem internen Know-how im Unternehmen ab. In der Praxis ist zwischen drei verschiedenen Rollen zu differenzieren, die sich z. T. auch je Produkt unterscheiden können:

Variante 1: Netzbetrieb

In dieser Rolle positioniert sich das EVU ausschließlich als Netzbetreiber des lokalen LoRaWAN-Netzes. Im Kern umfasst dies die Netzplanung und den Ausbau sowie den Betrieb des Netzes. Auf Wunsch des Kunden kann das EVU auch die Bereitstellung von Rohdaten aus der eigenen IoT-Plattform, hier IoT-Data-Hub genannt, anbieten. Daneben hat der Netznutzer die Möglichkeit, eigene Sensorik in das Netz einzuhängen und die Daten selbst zu verarbeiten. Das EVU agiert somit in der Variante Netzbetrieb als reiner Konnektivitätsdienstleister. Preismodelle orientieren sich daher i. d. R. an jedem eingehängten Device im Netz.

Variante 2 Netz- & IoT-Datahub-Betrieb

Die Variante Netz- & IoT-Data-Hub-Betrieb baut auf der ersten Variante Netzbetrieb auf. Dieses LoRaWAN-Geschäftsmodell orientiert sich nicht nur an der bloßen Bereitstellung des Netzes. Ergänzt wird die Dienstleistung des Netzbetriebs durch die Bereitstellung eines IoT-Data-Hubs. In diesem kann der Kunde seine Sensoren konfigurieren und Daten verwalten. Die Bereitstellung einer Datenplattform hat für das EVU den Vorteil, dass die Dienstleistung auch für weniger technikaffine Kunden interessant wird. Ein reiner Netzbetrieb zielt eher auf technisch fokussierte Kunden ab, da die benötigte IT-Infrastruktur zur Aufbereitung und Integration der Daten in die Fachprozesse durch den Kunden selbst erfolgen muss. Der IoT-Data-Hub stellt somit einen zusätzlichen Service da.

Des Weiteren übernimmt das EVU auch das Sensormonitoring. Im Netzbetrieb liegt der Service ausschließlich auf dem Monitoring der Gateways und des LoRaWAN-Netzwerkservers. Ist ein Sensor länger offline, informiert das EVU den Kunden über die fehlenden Datenpakete. Zusätzlich kann das EVU bei der Datenaufbereitung innerhalb des IoT-Data-Hubs unterstützen.

Variante 3 Full-Service-Dienstleister

Die dritte Variante Full-Service-Dienstleister stellt das komplette Dienstleistungspaket durch das EVU dar. Es übernimmt sämtliche Aufgaben, die für die Umsetzung von Produkten erforderlich sind. Dies umfasst auch den Fieldservice für die Integration der Sensoren vor Ort. Die Bereitstellung und Aufbereitung der Daten erfolgt immer durch das EVU. In diesem Zusammenhang ist zu analysieren, ob eine Datenbereitstellung als Data-as-a-Service für den Kunden im Vordergrund steht und weniger ein vollständiger Zugriff auf den IoT-Data-Hub.

LoRaWAn Dienstleisterrollen

Schritt 2: Dienstleistungstiefe des LoRaWAN-Geschäftsmodells bestimmen

Nach der Definition der Rolle als LoRaWAN-Dienstleister am Markt ist die genaue Dienstleistungstiefe zu definieren. In diesem Beispiel gehen wir davon aus, dass sich das EVU dafür entscheidet, die Variante 2 Netz- & IoT-Data-Hub-Betrieb umzusetzen. Für den Aufbau des LoRaWAN-Geschäftsmodells sind im ersten Schritt die Basisdienstleistungen auszuprägen. Im Folgenden soll noch einmal konkret auf die einzelnen Bausteine eingegangen werden.

LoRaWAN-Netzbetrieb, Gateway-Management, Netzplanung & Aufbau

Die erste Basisdienstleistung stellen der Netzbetrieb und das Gateway-Management dar. Dies umfasst den Betrieb des LoRaWAN-Netzwerk-Servers (LNS) sowie den Aufbau und Betrieb der LoRaWAN-Gateways. Die Verfügbarkeit der Gateways sowie das Firmwaremanagement liegen somit beim EVU als Netzbetreiber. Die Konnektivität für den Kunden ist so gesichert. Die technischen Mindestanforderungen für die Nutzung des Netzes und den Einsatz der zugelassenen Sensorik sowie Gateways erfolgt durch das EVU. Das EVU stellt dem Netznutzer auch die Information über die LoRaWAN-Netzabdeckung zur Verfügung.

Datenplattform

Der zweite wichtige Dienstleistungsbaustein zum Aufbau des LoRaWAN-Geschäftsmodells ist die Datenplattform. Auf ihr werden die Daten aus dem LNS entschlüsselt. Die Datenaufbereitung und
-bereitstellung an Drittsysteme kann ebenfalls über die Datenplattform erfolgen. Die Datenplattform ist die wesentliche Schnittstelle zum Kunden, auf der er seine Daten und Sensoren verwalten kann.

Sensorik Netzbetrieb

Neben der Sensorik kann das EVU das Monitoring der LoRaWAN-Sensorik übernehmen. Hierzu überwacht es den Datenverkehr im Netz, behebt Störungen, informiert den Kunden über fehlende Konnektivität und übernimmt ggf. Teile des Firmwaremanagements. Es berät außerdem den Kunden bei technischen Fragestellungen im Rahmen der Einbindung der Sensorik. Des Weiteren stellt das EVU die Einhaltung des Duty Cycle sicher.

Assetmanagement

Da das EVU für den Aufbau und Betrieb des Netzes verantwortlich ist, übernimmt es die Verantwortung für die Stammdaten sowie die Dokumentation der Gateways und Gatewaystandorte. Das Assetmanagement nimmt somit eine zentrale Rolle ein. Vor allem dann, wenn Dritte berechtigt sind, selbst Gateways in das Netz zu integrieren. Hier benötigt das EVU ein Zugriffsrecht und eine Information über die Art der Gateways sowie Ansprechpartner im Störungsfall.

Datenbereitstellung

Ein weiterer zentraler Dienstleistungsbaustein ist neben der Datenplattform die Datenbereitstellung. Selten reicht die Verarbeitung in der Datenplattform für den Kunden aus. Vielmehr geht es darum, die Daten mit anderen Datenbanken zu kombinieren und dem Anwender im jeweiligen Fachsystem bereitzustellen. Dies kann über unterschiedliche Schnittstellen wie MQTT oder auch die gute alte csv-Datei erfolgen. Für die Wartung der Schnittstelle ist im Regelfall der Kunde verantwortlich. Das EVU unterstützt bei der Bereitstellung der Daten. Die genaue Ausprägung ist im Einzelfall jedoch je nach angebotenem Produkt zu definieren.

Anwendung Einfach

Im ersten Schritt ist eine Integration der Fachprozesse meist nicht sofort erforderlich. Oft reichen schon erste einfache Dashboards, um einen Informationsmehrwert zu bieten. Eine Prozessintegration in das Fachsystem erfolgt häufig erst im Anschluss. Das LoRaWAN-Geschäftsmodell besteht in diesem Fall daraus, dem Kunden einfache kleine Dashboards oder Regelwerke bereitzustellen. Dies kann z. B. über ein Grafana Dashboard oder eine E-Mail-Notification erfolgen. Das EVU unterstützt in diesem Fall als Dienstleister bei der Umsetzung. In der Variante 2 Netz- & IoT-Data-Hub-Betrieb übernimmt im Regelfall der Kunde diese Aufgabe. Nach Absprache kann dies auch gegen Entgelt über das EVU geschehen.

Fieldservice

Für die Umsetzung von LoRaWAN-Produkten sind Sensoren im Feld zu verbauen. Der Fieldservice umfasst somit den Einbau, Betrieb und die Wartung der Sensorik. Im Normalfall erfolgt dies durch den Kunden selbst.

Anwendungen Individual/Komplex

Neben einfachen Dashboards oder der Integration der Informationen in bestehende IT-Systeme ist in manchen Fällen die Entwicklung neuer, komplexerer Softwarelösungen erforderlich. Die Umsetzung erfolgt meist durch einen Dienstleister, da das EVU selten eigene Entwicklungskompetenzen im Haus hat. Das EVU kann die neue Software seinen Kunden jedoch als SaaS-Lösung bereitstellen und so das eigene LoRaWAN-Geschäftsmodell weiter ausbauen. Komplexe Anwendungen sind allerdings immer einzelfallabhängig vom jeweiligen Produkt und den Kundenanforderungen.

Optionale Dienstleistungen

Neben den aufgeführten Aufgaben und möglichen Dienstleistungsfunktionen steht es dem EVU natürlich frei, weiterführende optionale Dienstleistungen anzubieten. Dabei kann es sich z. B. um das Testing und die Auswahl verfügbarer Sensoren handeln. Ebenso können weiterführende Entwicklungsleistungen oder die Umsetzung spezieller IT-Schnittstellen übernommen werden. Der Kreativität des EVUs sind an dieser Stelle keine Grenzen gesetzt.

LoRaWAN Geschäftsfelder im Überblick

Schritt 3: Produktgestaltung LoRaWAN-Geschäftsmodell

Parallel zum zweiten Schritt, der Bestimmung der Dienstleistungstiefe, sollte die Produktausgestaltung unter Berücksichtigung der Nutzerbedürfnisse erfolgen. Hierbei ist je Produkt im Einzelfall zu definieren, was genau als Leistung angeboten wird und wie die Preisgestaltung auszusehen hat. Im Rahmen der Preisgestaltung sind verschiedene Variationen möglich:

Monatliche Pauschale

Eine einfache Möglichkeit ist eine pauschale, monatliche Gebühr für die Nutzung des Netzes und der Datenplattform. Diese kann sich an einem Mengengerüst orientieren, wie z. B. bestimmten Schwellenwerten der Anzahl der Sensoren im Verteilnetz.

Konnektivitätspreis

Eine weitere Möglichkeit ist die Bepreisung der Konnektivität. Dies kann z. B. eine gewisse Menge an LoRa-Datenpaketen sein. Das entspricht dem Prinzip wie im Mobilfunkbereich, bei dem der Nutzer für ein bestimmtes Datenvolumen einen monatlichen Betrag zu entrichten hat. Die Konnektivitätskosten sollten jedoch geringer sein als übliche Mobilfunktarife.

Data-as-a-Service

Statt einer Gebühr für die Nutzung der Infrastruktur oder die Bereitstellung der Konnektivität kann der Kunde auch eine Gebühr für die Datenbereitstellung bezahlen. Im Geschäftsmodell Data-as-a-Service zahlt der Kunde für die Bereitstellung der Daten in einer vereinbarten Granularität und Verfügbarkeit. Die Bereitstellung der Infrastruktur gerät so in den Hintergrund. Vielmehr steht der Service bzw. das Produkt und der damit verbundene Informationsmehrwert im Vordergrund.

Mischkalkulation Platform-as-a-Service

Grundsätzlich ist auch immer eine Mischkalkulation in Abhängigkeit von den angebotenen Produkten möglich. So können einzelne Produkte als Data-as-a-Service angeboten werden, bei den eine weitere Nutzung des Netzes nicht möglich ist. Hierfür ist ein Entgelt für die Konnektivität je Sensor zu entrichten oder eine vereinbarte monatliche Pauschale. Allgemein steht es dem EVU aber frei, selbst ein geeignetes Modell zur Preisgestaltung zu finden.

Fazit LoRaWAN-Geschäftsmodell

Der Aufbau und die Etablierung der eigenen IoT-Sparte, verbunden mit der Etablierung eines neuen Geschäftszweigs, ist individuell zu definieren. Entscheidend können hierbei das zur Verfügung stehende Personal, die Prozesse innerhalb des EVUs, aber auch die angestrebte Dienstleisterrolle vom reinen Netzbetreiber bis zum Full-Service-Dienstleister sein. Ausgangsbasis sollte aber immer ein bestehendes Organisationskonzept sowie Serviceprozesse zur Gewährleistung des Betriebs der Produkte sein. Hinzu kommt die Notwendigkeit der Definition technischer Mindestanforderungen zur Gewährleistung eines Netzbetriebs. Je nach Ausgestaltung kann auch eine Zertifizierung des Netzes nach dem TKG erforderlich sein. Als items GmbH unterstützen wir eine Vielzahl von Stadtwerken bei der Etablierung der eigenen IoT-Sparte im EVU.

Bei Fragen zu diesem Blogbeitrag meldet euch gerne. Wenn euch der Artikel gefallen hat, abonniert gerne unseren Blog.

Hoch hinaus beim LoRaWAN-Netzaufbau

Die Standortsuche: Ober sticht Unter

Der LoRaWAN-Netzaufbau stellt jedes Stadtwerk vor eine erste Grundherausforderung. Welche Standorte sind geeignet und welche technischen Restriktionen sind zu beachten? Um ein solches Netz zu errichten, sind potenzielle Standorte zur Installation von LoRa-Gateways erforderlich. Als Erstes gelangen natürlich firmeneigene Standorte in den engeren Fokus, da keine Miet- oder Pachtkosten für den Gatewaystandort anfallen. Zusätzliche Themen wie Stromversorgung, Blitzschutz oder Zugangsrechte sind auch einfach zu organisieren.

Besteht für die Abdeckung des gewünschten Gebiets der Bedarf einer Installation zusätzlicher Gateways, geht der Blick bei der weiteren Standortsuche gerne „nach oben“. Die Höhe ist das A und O für eine gute Netzabdeckung, wie folgendes Bild schematisch zeigt:

Funkverhalten von LoRaWAN Gateways

Während in ländlichen Gebieten das höchste Bauwerk oft Kirchen bzw. die dazugehörigen Türme sind, werden diese in Städten durch Hochhäuser oder von einem Funk- oder Fernsehturm übertroffen. So zum Beispiel auch in der nordrhein-westfälischen Landeshauptstadt Düsseldorf. Hier begleitet items die Stadtwerke Düsseldorf beim Aufbau eines LoRa-Netzes, in so genannten Zukunftsvierteln.

Vorbereitung und Installation

Das höchste Hochhaus Düsseldorfs ist mit 125 Metern immer noch um einiges niedriger als der Rheinturm mit seiner Gesamthöhe von 240,5 Metern und den Plattformen auf mehr als 160 Metern. Somit ist der Standort prädestiniert für die Platzierung eines LoRa-Gateways.

Der Rheinturm wird, wie auch andere Funktürme, durch die DFMG Deutsche Funkturm GmbH (DFMG) betrieben. Fasst man einen solchen Standort für den LoRaWAN-Netzaufbau der DFMG ins Auge, sind folgende Aspekte zu beachten.

Der erste und wohl auch naheliegendste Punkt: Es ist ein Mietvertrag abzuschließen. Die Grundlage dessen ist u. a. eine Ausführungsplanung, die durch ein von der DFMG vorgegebenes Ingenieurbüro zu erstellen ist. Zur Erstellung dessen kann unter Umständen eine Vor-Ort-Begehung notwendig sein, bei der z. B. geprüft wird, wie die Stromversorgung an der gewünschten Stelle zu erweitern ist.

Sind die Ausführungsunterlagen erstellt, von der DFMG abgenommen und ist der Mietvertrag unterschrieben, kann der Bau beginnen, der je nach Ausgangssituation wie folgt aussehen kann:

Die Stromversorgung wird durch ein von der DFMG vorgegebenes Unternehmen erstellt.
Die Baustelle wird min. vier Wochen vor Baubeginn angemeldet. Die notwendigen Stahlbauarbeiten sind durchzuführen.
Das Gateway und notwendiges Zubehör sind zu installieren. Die Bauarbeiten sind dabei, wie von der DFMG und dem Ingenieurbüro, das die Ausführungsunterlagen erstellt hat, vorgegeben, zu dokumentieren. Der Abschluss der Bauarbeiten ist der DFMG zu melden.
Das Ingenieurbüro erstellt den Bestandsplan und die DFMG erteilt die Bauabnahme.

Lessons Learned beim LoRaWAN-Netzaufbau

Von der ersten Anfrage bei der DFMG bis zur Abnahme des installierten Gateways kann der Prozess mehrere Monate dauern. Die Dienstleister waren zu beauftragen, deren Arbeit zu koordinieren und abzunehmen. Termine waren abzustimmen und Vorlaufzeiten zu berücksichtigen. Die Vielzahl der beteiligten Akteure erzeugte einen hohen Abstimmungsaufwand: Beteiligt waren DFMG (mit Asset Management und kaufmännischer Abteilung), das Ingenieurbüro für die Aufbau- und Bestandsplanung, ein Elektroinstallateur und Stahlbauer.

LoRaWAN-Netzaufbau: Installation mit 1a Aussicht und Maskottchen

Doch der Aufwand für einen erfolgreichen LoRaWAN-Netzaufbau lohnt sich: In stichpunktartigen Tests, mit einem Feldtester im PKW, wurden in verschiedenen Himmelsrichtungen Reichweiten von zwölf und mehr Kilometern erzielt. Der Spitzenwert lag bei 26 km.

Da im Stadtgebiet bis dahin erst zwei weitere Gateways installiert waren, sendeten einige Sensoren mit hohen Spreadingfaktoren. Außerdem gingen Pakete von in Schächten installierten Sensoren vereinzelt verloren. Nach der Installation auf dem Rheinturm sind die Spreadingfaktoren und Paketverluste deutlich gesunken. Die damit einhergehende verlängerte Batterielebensdauer sowie die Entlastung des Duty Cycles sind weitere positive Effekte für den Netzbetrieb.

LoRaWAN-Netzaufbau der Zukunft: Grid Insight: LPWAN

Die Projekterfahrung zeigt einmal mehr: je höher die Montage des Gateways, desto besser die Abdeckung. Diese These konnte schon in vielen weiteren Projekten und Simulationen bestätigt werden.

Gerade in der Praxis zeigt sich, dass für einen vollständigen LoRaWAN-Netzaufbau und -betrieb eine Informationsbasis zur tatsächlichen Netzabdeckung und Netzqualität gefragt ist.

Aus diesem Grund entwickelt items zusammen mit mehreren Stadtwerken das Tool Grid Insight: LPWAN, um jedem LoRaWAN-Netzbetreiber eine Aussage über die eigene Netzabdeckung in Form einer Heatmap zur Verfügung zu stellen. Eine gezielte Netzplanung und eine nachgelagerte Analyse mit Grid Insight: LPWAN bilden für viele unserer Kunden die Basis dafür, erfolgreich ein LoRaWAN-Netz zu betrieben und Anwendungsfälle realisieren zu können.

Grid Insight: LPWAN – Lösungsbausteine & Fragestellungen

Die technischen Mindestanforderungen (TMA) für das LoRaWAN-Netz

TMA LoRaWAN-Netz: Warum ein technisches Regelwerk notwendig ist

In den klassischen Energieinfrastrukturen wie Strom, Gas, Wasser oder Fernwärme ist die Einhaltung von technischen Mindeststandards zur Gewährleistung der Systemstabilität und Qualität längst selbstverständlich. Die wahrscheinlich bekanntesten technischen Mindeststandards in der Energiebranche stellen vermutlich die technischen Anschlussbedingungen (TAB) im Stromnetz da.

Dabei handelt es sich um ein Regelwerk für den Anschluss von Kundenanlagen an das Niederspannungsverteilungsnetz (0,4 kV). Dieses Regelwerk definiert die grundsätzlichen Anforderungen des Verteilungsnetzbetreibers an den Netzanschluss, die Kundenanlage und den Betrieb einer Anlage. Der Anlagenbetreiber ist verpflichtet, diese Bedingungen einzuhalten. Durch die Festlegung einer einheitlichen, technischen Vorgehensweise soll die Systemstabilität des Netzes langfristig sichergestellt werden. Auf Grund der guten Erfahrungen der letzten Jahrzehnte hat sich für jede Infrastruktursparte die Definition einheitlicher, technischer Regeln durchgesetzt.

Mit der neuen Marktentwicklung von Stadtwerken, IoT-Infrastrukturen wie u. a. LoRaWAN-Netze zu betreiben, stellt sich ähnlich wie bei Energienetzen die Frage, nach welchen technischen Regeln dieses Netz betrieben werden soll. Denn durch die zunehmende Bereitstellung der Infrastruktur an Dritte, zur Erschließung neuer Geschäftsfelder, wird die Regelung einer einheitlichen Nutzung zunehmend wichtiger. Aus diesem Grund hat die items GmbH zusammen mit einigen ihrer Kunden einen ersten Entwurf für eine TAB unter dem Namen technische Mindestanforderungen (TMA) erstellt.

TMA LoRaWAN-Netz: Überblick über die wesentlichen Regelungen

Zur Sicherstellung der technischen Mindeststandards (TMA) für LoRaWAN-Netze sind eine Vielzahl von Regelungen zu treffen. Einen groben Überblick möglicher Bausteine soll in diesem Abschnitt gegeben werden:

LoRaWAN-Gateways: Ein wesentliches Thema des LoRaWAN-Netzbetriebs ist die Festlegung der Mindeststandards für die Gateways in der TMA. Hierzu zählt u. a. die Festlegung, welche Geräte durch den LoRaWAN-Netzbetreiber zugelassen sind. Zwar ist in der Theorie ein Herstellermix möglich, erhöht jedoch langfristig den Wartungsaufwand, da bestimmte Prozesse wie das Einspielen von Updates unterschiedlich funktionieren. Oft verwenden die Hersteller auch unterschiedliche Gatewaymanagementsysteme, so dass ein Überblick mittelfristig schwieriger wird. Daneben ist eine Vielzahl von anderen Faktoren zu regeln, z. B. wie eine Montage der Geräte zu erfolgen hat, wer die Geräte verwalten und aufbauen darf, wie eine Erschließung des Standortes erfolgt usw.

Sensorik: Neben den LoRaWAN-Gateways gilt es, die Mindestanforderungen an die Sensorik zu definieren. So ist z. B. die Festlegung der Einhaltung deutscher, technischer Mindeststandards je Sensorik zwingend erforderlich, da noch immer eine Vielzahl mangelhaft verarbeiteter Hardware im Umlauf ist. Daneben ist eine wichtige Regelung die Einhaltung des Duty-Cycle, um langfristig die Stabilität des eigenen LoRaWAN-Netzes zu gewährleisten. Zudem ist zu regeln, wer im Fall eines Verstoßes die Sensorik aus dem Netz entfernen darf.

IT-Sicherheit: Wie bei jeder anderen IT-Infrastruktur auch, sind neben den Anforderungen an die Hardware technische Mindestanforderungen an das LoRaWAN-Netz im Rahmen der IT-Sicherheit zu definieren. Dazu zählt sicherlich, ob die IT-Infrastruktur in einer Cloud oder einem Rechenzentrum betrieben werden soll. Auch ist z. B. festzulegen, wie die Gateways zum LNS abzusichern sind (Bsp. Glasfaseranschluss, M2M-Simkarten etc.).

IT-Infrastruktur & Schnittstellen: Im Rahmen des Betriebs der IT-Infrastruktur ist u. a. zu definieren, welche Infrastruktur vom Netzbetreiber vorgegeben ist und welche durch den Netznutzer selbst auswählbar sind. Zwingend erforderlich ist eine Festlegung des eingesetzten LoRaWAN-Netzwerk-Servers (LNS) und eine Regelung, wie Daten an externe LoRaWAN-Netze bereitzustellen sind. Aktuell empfehlen wir hier den Einsatz eines Multiplexers, um den Aufbau paralleler Netzinfrastruktur zu vermeiden.

Kritis-Prozesse: Da eine Vielzahl der LoRaWAN-Anwendungsfälle im Kritis-Bereich wie z. B. Stromnetze erfolgen können, ist zu klären, ob hierfür eine zusätzliche Regelung erforderlich ist. Beispielsweise kann die Festlegung eines n-1-Kriteriums für Gateways erfolgen, um im Fall eines Gatewayausfalls die Betriebsfähigkeit weiterhin sicherzustellen. Auch sollte u. a. eine Regelung getroffen werden, wie diese Informationen zu schützen sind. Aktuell empfehlen wir, hier z. B. eine Weiterleitung der Daten in das TTN-Netzwerk zu verbieten, da die Frage des Dateneigentums nicht geklärt ist.

Assetmanagement: Ein wichtiges Thema ist der Bereich des Assetmanagements. Vor allem dann, wenn es auch Dritten gestattet ist, Gateways im LoRaWAN-Netz einzubinden. Sollten darüber hinaus externe Standorte genutzt werden, sollten die Bedingungen der Zutrittsregeln abgestimmt sein. Ebenso sollte der Netzbetreiber die Möglichkeit haben, zur Sicherstellung des Betriebs Zugriff auf die Gateways des Dritten zu haben. Daneben sollte die Verwaltung des Assetmanagements der Gateways zentral durch den Netzbetreiber erfolgen. Die erforderlichen Informationen sollten in den TMA festgehalten werden.

Netzabdeckung & -ausbau: Ein weiteres Thema ist die Regelung der Messung der Netzabdeckung und des -aufbaus. Daneben ist zu klären, wer für die Verdichtung verantwortlich ist und welche Rechte der Netznutzer gegenüber dem Netzbetreiber hat. Empfehlenswert ist es außerdem, wenn der Netzbetreiber dem Netznutzer Informationen über die aktuelle Netzabdeckung bereitstellt und die Informationen regelmäßig aktualisiert.

Technische Mindestanforderung (TMA) LoRaWAN-Netze – Themenübersicht

TMA LoRaWAN-Netz: Handlungsempfehlung

Mit der Entwicklung eigener technischer Mindestanforderungen (TMA) für das LoRaWAN-Netz sollten Stadtwerke spätestens dann beginnen, wenn eine Nutzung des Netzes durch Dritte geplant ist. Allerdings kann dies auch schon vorher erforderlich sein, wenn die Größe des Stadtwerks einen kritischen Schwellwert überschreitet und eine Vielzahl von Abteilungen das Netz nutzt. Wie bei allen Kommunikationsnetzen ist auch die Störung eines LoRaWAN-Netzes möglich, weswegen die Festlegung technischer Mindestanforderungen eine erste Präventionsmaßnahme darstellt, auf der auch die Festlegung von (künftigen) Betriebsprozessen möglich ist. Zum aktuellen Zeitpunkt verfügen wenige LoRaWAN-Netzbetreiber über eine TMA. Mit der zunehmenden Vermarktung des Netzes und der Öffnung für Dritte ist auch hier wie bei allen anderen Infrastrukturen von Stadtwerken von einem technischen Mindeststandards auszugehen.

Service der items

Da die items zahlreiche Stadtwerke auf den Weg zum IoT-Netz- und Plattformbetreiber begleitet sowie in der Projektumsetzung unterstützt, wurde zusammen mit mehreren Kunden eine erste Version der TMA erstellt. Diese kann gegen eine Einmalgebühr von der items bezogen werden. Daneben haben Stadtwerke die Möglichkeit, einen TMA-Servicevertrag abzuschließen, über den eine jährliche Überarbeitung der TMA erfolgt und dem Kunden zugstellt wird. Auf Grundlage des Musterentwurfs kann dann eine individuelle Anpassung erfolgen. Darüberhinaus unterstützen wir Kunden bei der Entwicklung ihres Organisations- und Netzbetriebskonzept für einen erfolgreichen Aufbau Ihrer IoT-Sparte. Bei Interesse an der ersten Version der TMA oder bei Beratungsbedarf zu der Thematik sprechen Sie uns gerne an.