M. Sc. Marek Kretzschmar Westsächsische Hochschule Zwickau Fakultät Wirtschaftswissenschaften Arbeitskreis Integrierte Informationssysteme IKT-Konzept zur Realisierung ubiquitärer Kraftwerke Energienetze der Zukunft Tagung im Rahmen der 22. Wissenschaftlichen Konferenz an der Hochschule Mittweida bkz - Bildungs- und Kommunikationszentrum im Wasserkraftwerk Mittweida 24. Oktober 2012
Agenda Einleitung Was ist ein Ubiquitäres Kraftwerk? Exkurs: Ubiquitous Computing Ubiquitäres Kraftwerk Modulares IKT-Konzept OSGi Standard für modulare Softwareentwicklung Aspekt Sicherheit Framework für die Visualisierung Anwendungsfall Datenvisualisierung Anwendungsfall Visualisierung für Elektromobilität Mobile Visualisierung Zusammenfassung und Ausblick 2
Einleitung Ziele: Bedarfsgesteuerte Erzeugung, Speicherung und Verteilung von Energie in lokalen Versorgungsnetzen (Strom, Gas, Wärme) Modulare, plattformunabhängige Softwarearchitektur Serviceorientierte Steuerungslogik und Algorithmen Bereitstellung von Visualisierungen für unterschiedlichste Akteure Automatische, Szenarien basierte Generierung der Oberflächen Steigerung der Akzeptanz von Smart Building Technologien bei relevanten Zielgruppen und Anwendern Aber: Benötigen ubiquitäre Kraftwerke, Smart Grids und intelligente Gebäude überhaupt Visualisierungen? Wäre ein transparente Steuerung nicht besser? 3
Ubiquitous Computing Im 21. Jahrhundert wird die technologische Revolution das Alltägliche, Kleine und Unsichtbare sein. *1+ Mark Weiser (1952-1999) Vision des Ubiquitous Computing (1991): Spezielle Hard- und Softwareelemente ( ) sind so allgegenwärtig, dass niemand deren Präsenz wahrnehmen wird. Erfüllen ihre Aufgaben im Hintergrund. [1] 1991 2012 2033? Mark Weiser: Ubiquitous Computing (1991!), aus [1] 4 Quellen: [1] Mark Weiser The Computer for the 21st Century, In: Scientific American Sept. 1991
Virtualisierung extern IF intern Ubiquitäres Kraftwerk Einbindung der Domänen Strom, Wärme, Gas dezentraler Ansatz; Virtualisierung der Ressourcen Managementsystem Erzeugergestellschaft Regelenergie Überschussmengen Übertragungsnetzbetreiber Sportmarkt Erzeuger Smart Control GP Virtuelles Kraftwerk Prognose Einsatzplanung Optimierung Dezentrales Energiemanagement System UKW Speicher Smart Control Kommunikationsnetz ISDN LAN/WAN GSM Web/XML Verbraucher Smart Control REA 1 REA 2 REA 3... REA 4 Energie Daten Informationen Geschäftsprozesse Virtuelles Kraftwerk, aus [1]. Grundgedanke: Verlagerung der Intelligenz der Geräte in das verteilte Softwaresystem Schaffung einer einheitlichen, verteilten Dienste (Distributed Services) Dynamische Anbindung neuer Ressourcen (Erzeuger, Speicher, Verbraucher) durch automatische Konfiguration (Plug&Play) 5 Quellen: [1] Lehnhoff, S.: Dezentrales vernetztes Energiemanagement, Vieweg+Teubner Verlag, Wiesbaden, 2010.
Integration von Energiespeichern Problem: Laut BNetzA im Jahr 2010 Ausfallarbeit von 127 GWh (2009: 74GWh) Einbindung unterschiedlicher Speichermedien und technologien wie bspw. Haushaltenergiespeicher Lageenergiespeicher Pumpspeicherwerke Power-To-Gas Power-to-Gas Prinzipskizze aus [1] Kopplung von Speichern (auch Querverbund) erfordert standardisierte IKT-Lösungen Durch modulare OSGi Architektur, Virtualisierung und serviceorientierte Konzepte erreichbar Baugruppenträger mit Haushaltenergiespeicher [2] 6 Quellen: [1] Power-to-Gas: Verfahrensschema und Einbindung in das Energiesystem. URL: http://www.zsw-bw.de/themen/brennstoffewasserstoff/power-to-gas.html [2] Hempel, T., Veit, B., Bodach, M,: Haushaltenergiespeicher. In: IWKM Scientific Reports, Vol. 6, 2011, pp.38-41.
Security Modulares Konzept Modularisierung: OSGi (I) Dynamisches Modulsystem für die Programmiersprache Java Spezifiziert von der OSGi Alliance (www.osgi.org) Baukastensystem für Software (Bausteine==Komponenten/Bundles) Ursprünglicher Einsatzzweck: Gebäudesystemtechnik (Residential Internet Gateways) Eclipse Equinox: Referenz der Eclipse Foundation (www.eclipse.org/equinox) Service-Plattform, Standard-Dienste (Core Specification): HTTP-Service (Webserver) Event Admin Service und viele weitere Fernmanagement von Komponenten (Bundles) und Diensten (Services) im Standard bereits vorgesehen OSGi Framework Service-Schicht Lifecycle-Management-Schicht Module-Schicht Execution Environment (JRE) Framework Services Betriebssystem Hardwareplattform Logische Schichten im OSGi Framework, nach [1] 7 Quellen: [1] Wüterich, G., Hartmann, N., Kolb, B., Lübken, M.: Die OSGi Service Plattform Eine Einführung mit Eclipse Equinox, dpunkt.verlag GmbH, Heidelberg, 2011
Modulares Konzept Modularisierung: OSGi (II) Definierter Lifecycle der Komponenten ermöglicht Hinzufügen, Austauschen und Entfernen einzelner Komponenten (Bundles) zur Laufzeit ( Live-Update einzelner Programmteile möglich!) Verwaltet Abhängigkeiten zwischen Bundles mit Hilfe von spezifischen Metadaten (Anreicherung der.jar Dateien) Komplexe verteilte Systeme mit Distributed OSGi realisierbar ( From Smart Building to Smart Grid ) install refresh/update INSTALLED STARTING OSGi OSGi resolve refresh/update start OSGi RESOLVED ACTIVE uninstall stop stop OSGi OSGi UNINSTALLED STOPPING OSGi OSGi Bundle Lifecycle, nach [1] 8 Quellen: [1] Wüterich, G., Hartmann, N., Kolb, B., Lübken, M.: Die OSGi Service Plattform Eine Einführung mit Eclipse Equinox, dpunkt.verlag GmbH, Heidelberg, 2011
Aspekt Sicherheit Sicherheit durch Kombination aus infrastrukturellen (1) und anwendungsfokussierten Technologien (2) 1. VPN, VLAN 2. Zertifikate, SSL/TLS Anwendungsbezogene Sicherheit, beispielsweise durch Nutzung des OSGi Security Layer Einhaltung grundlegender Sicherheitsrichtlinien bei der Entwicklung Beispiel: public class AlmostSecure { public AlmostSecure() { this.init(); } protected void init() { SecurityManager.check(); } } LAN 1 VPN + VLAN Switch WAN LAN 2 public class AlmostSecureOverridden { public AlmostSecureOverridden () { super(); } protected void init() { // Sicherheitsprüfung wird umgangen! } } 1 2 3 LAN 1 VLAN 1 VLAN n n WAN (VPN) LAN n VLAN VPN-Verbindung 9 Quellen: [1] http://de.slideshare.net/kaihackbarth/security-in-osgiapplications-robust-osgi-platforms-secure-bundles, Folie 21.
Aspekt Visualisierung Windows Requirements Engineering Nutzerorientierung Sicherheit Wiederverwendbarkeit Erweiterbarkeit, Wartbarkeit Plattformunabhängigkeit Einsatz der Programmiersprache Java ios Plattformunabhängigkeit Android Linux Evaluation Architekturvarianten: Klassisches Desktop-Programm vs. browserbasierte Anwendung Kommunikation (speziell im Umfeld mobiler Anwendungen) Zielgruppen u.a. Energieversorger (Monitoring, Leitstand), Verwaltung und Mieter im kommunalen Wohnungsbau (Smart Building), ext. Dienstleister, Elektromobilität 10
OSGi und Vaadin }> Framework für UI-Entwicklung: Vaadin (www.vaadin.com) Oberflächen werden in Java programmiert Client-Server-Architektur (Server: Java, Client: HTML+JS) Nutzt intern Google Web Toolkit (GWT) Java Quellcode (Compiler) HTML und JavaScript (Webseiten) Umfangreiche UI-Komponentenbibliothek, benutzerdefiniert erweiterbar Erweiterbar mit Add-Ons (bspw. Invient Charts, https://vaadin.com/directory#addon/invient-charts) Quelle: https://vaadin.com/directory#addon/invient-charts Web Browser Client-Side Engine Java Web Server Vaadin UI Components Java Applikation WebService EJB OSGi Communication Bundle OSGi HTTP Service UIComponents Bundle OSGi Application Bundle DB (indirekt über OSGi Service Bundle) Vaadin OSGi 11
OSGi basierte Visualisierung OSGi als Container (Ausführungsumgebung) für Softwarekomponenten Einheitliche Datenbasis für Dienste, Zugriff auf Daten nur über Services möglich Dienste kapseln Logik bzw. Algorithmen Komponenten für lokale Desktop-Applikationen (Java Swing API) Webserver-Dienst ermöglicht Zugriff auf Implementierungen der Web-Anwendungen HTTP-basierte Kommunikationsschnittstellen für mobile Anwendungen Lokale Anwendung Desktop-PC o.ä. Browser Mobile Geräte (z.b. Smartphone, Tablet) Browser Native App Host-Rechner OSGi Plattform HTTP WebSocket WebServices UI Level Java Swing UI WebServer (OSGi HTTP Service) UI-Bundles (Vaadin Servlets und Add-Ons) Communication-Bundles Service Level Service-Bundles Automatisierungs- und Persistenz-Komponenten Hardware-Ebene / Feldbus (z.b. KNXnet/IP, ModBus, RS-485, ) 12
Webbasierte Datenvisualisierung Prototypische Implementierung einer Anwendung zur Datenvisualisierung Dynamische Definition von Datenquellen (z.b. PV Freie Zuordnung von Datenquellen zu 1..n Diagrammen Unabhängig von der TGA, universell einsetzbar durch Virtualisierung DAVISU Datenvisualisierung für das ubiquitäre Kraftwerk 13
Visualisierung für Elektromobilität Realisierung einer Solar-Elektro-Tankstelle am August-Horch-Museum Zwickau Anzeige von Daten der PV-Anlage, Energiespeicher, Energieversorger (Einspeisung / Entnahme) sowie Zustand und Verbrauch der Ladestationen Betrachtung historischer Verläufe für o.g. Daten Authentifizierungs- und Abrechnungsdienst 190 W p pro Modul / gesamt 4,75 kw peak XML / WS MODBUS/TCP RS485 10kWh 14
Kommunikationsaspekte mobiler Apps Polemik der Paradigmen: Push vs. Polling Wie gelangen die Daten zum mobilen Gerät (visa versa)? (Transparent für Anwender, jedoch von hoher Bedeutung bei der Konzeption) Probleme im mobilen Umfeld: Nur eingeschränkte Ressourcen verfügbar (insbes. Akku) Volatile Netzverbindungen Spezifische Anforderungen und Möglichkeiten der verschiedenen Plattformen Aktuelle Trends: Cross Plattform Mobile Development für Apple ios, Google Android, Windows Phone; generische Entwicklung WebSockets nach IETF (RFC 6455) 1 als Kommunikationstechnologie Nutzung von HTML5 in browserbasierten Anwendungen Datenformate: XML, JSON 15 Quellen: [1] https://tools.ietf.org/html/rfc6455 (28.08.2012)
Beispiel mobile Visualisierung Beispiel - Mobile Anwendung für Elektromobilität (Android App) Prinzip Zugriff auf WebService der OSGi basierten IKT der Solar-Elektro-Tankstelle Bereits implementierte Funktionen Zustandsanzeige der einzelnen Ladestationen (frei, belegt, ladend) Anzeige aktueller Ertragswerte der PV-Anlage, Netzeinspeisung- und Entnahme sowie Speicherstatus Emobility OSGi Container HTTP Mobile Server Bundle UI Data Service Internet via GSM/HSCSD/GPRS /EDGE/UMTS/LTE/ Virtualization Bundles 16
Zusammenfassung und Ausblick Brauchen wir für ubiquitäre Kraftwerke also eine IKT-Architektur mit modularer Visualisierung? JA denn sie ist mehr als nur ein Spielzeug für Digital Natives 1 Informelle Übersicht ist gerade bei solch komplexen Systemen notwendig Trotz hochgradiger Automatisierung werden Anwender nicht auf manuelle Eingriffe verzichten wollen Für wissenschaftliche Untersuchungen (bzw. zeitnahe Auswertungen mit Hilfe von Diagrammen) anwendbar OSGi ist eine ideale Basis für komplexe und dennoch wart- und erweiterbare Softwaresysteme (Quelle: http://flickr.com/photos/tfrancis/539308690/) 17 1 Marc Prenzky: On the Horizon. MCB University Press, Vol. 9 No.5, October 2001.
Zusammenfassung und Ausblick Geplante Vorhaben: Echtzeitnahe Visualisierung von Daten (z.b. sekundengenaue Stromverbrauchsanzeige, um gezielt einzelne Extremverbraucher zu identifizieren) Touch- und Gesten-Steuerung auch im Desktop-Bereich (Windows 8?) Erweiterung der mobilen Anwendung um Funktionen wie Reservierung von Ladepunkten oder Anzeige von Verlaufsdiagrammen Einsatz der Softwarelösung in weiteren energiefokussierten Forschungsprojekten (auch Ambient Assisted Living) Ausbau der Emobility-Infrastruktur an der WHZ und im Raum Zwickau unter Anwendung der OSGi-Architektur 18
Vielen Dank für Ihre Aufmerksamkeit! Kontakt: Marek Kretzschmar Westsächsische Hochschule Zwickau Fakultät Wirtschaftswissenschaften marek.kretzschmar@fh-zwickau.de +49 (0375) 536-3266 http://aiis.fh-zwickau.de 19