Konsortiale Open-Source-Softwareentwicklung für die Netzleittechnik - openkonsequenz

Transkript

1 Konsortiale Open-Source-Softwareentwicklung für die Netzleittechnik - openkonsequenz Symposium Netzleit-, Zähler- & Informationstechnik 03. bis 04. September 2014, Weimar Frank Rose, Michael Müller

2 Agenda 1. Ausgangslage und Zielsetzung aus Sicht der Netzbetreiber 2. Ergebnisse der Machbarkeitsstudie 3. Vor- und Umsetzungsprojekt 4. Aktueller Stand 5. Fazit Seite 2

3 Agenda 1. Ausgangslage und Zielsetzung aus Sicht der Netzbetreiber 2. Ergebnisse der Machbarkeitsstudie 3. Vor- und Umsetzungsprojekt 4. Aktueller Stand 5. Fazit Seite 3

4 Ausgangslage aus Sicht der Netzbetreiber Datenpflege Einspeisemanagement HEO Prognose Archiv Schnittstellen Schnittstellen Schnittstellen Rumpf- SCADA. Schaltanträge Die heutigen Leitsysteme sind sehr umfangreich und damit hochkomplex geworden Jeder Hersteller muss alle Funktionalitäten für sein (proprietäres) Leitsystem entwickeln Spätere Ergänzungen bzw. Nachträge sind sehr aufwändig und oft nicht empfehlenswert Modularität ist nicht gegeben, das Leitsystem ist für den Nutzer als Ganzes eine Blackbox, die proprietär programmierte Software für den Nutzer nicht anpassbar Seite 4

5 Ausgangslage aus Sicht der Netzbetreiber IT-Systeme zur Netzführung sind bei den Netzbetreibern über Jahre historisch gewachsen Leitsysteme sind häufig Inselsysteme Beschreibung des Zustandes der Software zum Betrieb der Netze: mehrfach redundante Datenhaltung in verschiedenen Systemen komplexe Schnittstellen mit hohem Pflegeaufwand starke Abhängigkeit von einigen wenigen Systemlieferanten geringer Einfluss auf Produktentwicklung und Lieferzeiten (mangelnde Transparenz für den Netzbetreiber) Folge ist IT-Kosten sind signifikant hoch und können kaum beeinflusst werden Es wird immer schwerer regulatorische Zeitvorgaben zu erfüllen Funktionalität der IT-Werkzeuge ist nicht immer bedarfsgerecht Vendor-lock-in für den Kunden (Hersteller stehen bei Leitsystemerweiterungen in keinem Wettbewerb) Seite 5

6 Zielsetzung für die alternative Softwarelösung Datenpflege Einspeisemanagement HEO Prognose Archiv Schnittstellen Schnittstellen Schnittstellen Rumpf- SCADA. Schaltanträge Die Komplexität wird zerschnitten, die Funktionen liegen als einzelne Module vor Die Hersteller können Funktionalitäten fremder Hersteller an ihr Leitsystem anbinden Spätere Ergänzungen bzw. Nachträge erfolgen als Module über klar definierte Schnittstellen (Adapter und Konnektoren) Das Leitsystem kann modular, anforderungsgerecht weiterentwickelt werden. Seite 6

7 Zielsetzung für die alternative Softwarelösung Lösungsansatz und Rahmenbedingungen für die Zielerreichung Gründung eines Konsortiums (kooperative Solidargemeinschaft) zur Entwicklung von Software unter einer Open-Source-Lizenz, d. h. geistiges Eigentum der Software liegt beim Anwender und nicht beim Hersteller Anwender entwickeln die Software nicht selber, aber die Hersteller legen den Quellcode offen Wettbewerb bei Ausschreibung neuer Module SCADA-Funktion ist nicht Bestandteil der Betrachtung Haftungsfrage bei Softwarefehlern muss geregelt sein Zielsetzung aus Sicht der Netzbetreiber Abhängigkeit von einem Hersteller verringern (Vendor-lock-in) Erzielung von Kosteneinsparungen im Vergleich zur konventionellen Vorgehensweise Software-Qualität und -Ergonomie sowie IT-Sicherheit steigern Zeitliche Umsetzung von Projekten beschleunigen Innovationen von Softwareentwicklung fördern Seite 7

8 Agenda 1. Ausgangslage und Zielsetzung aus Sicht der Netzbetreiber 2. Ergebnisse der Machbarkeitsstudie 3. Vor- und Umsetzungsprojekt 4. Aktueller Stand 5. Fazit Seite 8

9 Roadmap Machbarkeitsstudie Vorprojekt Umsetzungsprojekt Zielsetzung: Prüfung der technischen Einsetzbarkeit von Open-Source- Software im Leitsystembereich Betrachtung der organisatorischen Umsetzbarkeit Grobe Abschätzung der Wirtschaftlichkeit Beachtung der üblichen Anforderungen für Leitsysteme (Verfügbarkeit, Sicherheit, Haftung etc.) Sept Jul Sep Zielsetzung: Einbindung von Herstellern, wissenschaftlichen Instituten und Netzbetreibern Spezifikation zum Last- und Einspeisemanagement Kosten-/Nutzen-Verifizierung Konkretisierung System- und Softwarearchitektur sowie Entwicklungsumgebung Mögliche Geschäftsmodelle Prüfung weiterer Open- Source-Komponenten Zielsetzung: Umsetzung des organisatorischen Rahmens für die Anwender und Hersteller Umsetzung des Last- und Einspeisemanagements auf Open-Source-Basis Entwicklung weiterer Open- Source-Komponenten Weiterentwicklung des Konsortiums Seite 9

10 Open-Source in anderen Industrien Kann die Idee der konsortialen Entwicklung von Open-Source-Software durch eine Anwendergemeinschaft nachhaltig umgesetzt werden? Ja! Folgende Beispiele bestätigen dies: Gemeinsame Entwicklung von Software auf Open-Source-Basis ist heute bereits in der Industrie etabliert Seite 10

11 Sicherheit und Strategische Position BSI Seite 11

12 Auszug aus dem aktuellen Koalitionsvertrag Seite 12

13 Technische Machbarkeit System-/Softwarearchitektur und Entwicklungswerkzeuge Technische Machbarkeit hängt davon ab, ob die Anforderungen an die Qualität der Software erfüllt werden können 1. System- und Softwarearchitektur Definition Softwarekomponenten, -plattformen und Standards Definition nichtfunktionaler Anforderung wie Datenintegrität, Vertraulichkeit, Verfügbarkeit (Redundanz, Roll-Back), Funktionalität und Zeitverhalten (Echtzeitfähig) Umsetzung möglichst mit Open-Source-Komponenten 2. Entwicklungswerkzeuge und -prozesse Nutzbarmachung und Organisation Entwicklungskapazitäten Sicherstellung, der geforderten Anforderungen wie Modularität, (Langzeit-)Wartbarkeit, Sicherheit und höhere Qualität (Reifegrad, Fehlerfreiheit...) Seite 13

14 Technische Machbarkeit Zusammenfassung Grundwerte (BSI): Datenintegrität - sehr hoch Verfügbarkeit - hoch Vertraulichkeit - normal Qualität: Funktionalität und Zeitverhalten Reifegrad und Fehlerfreiheit Modularität und Anpassbarkeit (Langzeit-) Wartbarkeit verbesserte Ergonomie Ist vor diesem Hintergrund die technische Machbarkeit für eine konsortial entwickelte Open- Source-Lösung gegeben? Ist Open-Source-Software sicher? Ist Open-Source-Software von hoher Qualität? Seite 14

15 Geschäftsmodell Open-Source-Konsortium-Model bietet entscheidende Vorteile: Konsortium (der Anwender) ist Inhaber der Lizenzrechte Offenheit und Langzeitwartbarkeit ist gesichert Großes Einsparpotenzial, da herstellerbezogene Kostenpositionen nicht anfallen Vendor-Lock-in wird überwunden Die Anwender haben im Open-Source- Konsortium-Model Einfluss auf die gesamte Wertschöpfungskette Seite 15

16 Organisatorische Machbarkeit Die Machbarkeitsstudie empfiehlt nach einem Vergleich der möglichen Rechtsformen die Gründung einer Genossenschaft (e.g.) zu einem geeigneten Zeitpunkt Genossenschaftskonsortium vertritt vorrangig die Interessen der Anwender ist Auftraggeber für die Entwicklung der Software in einem etablierten Ökosystem (von Anforderung bis Abnahme) wird möglichst vollständig Eigentümer des Source Codes und bestimmt damit die Lizenz stellt die konsortial entwickelte und getestete Software zum Download bereit Seite 16

17 Wirtschaftlichkeit Der Nachweis der Wirtschaftlichkeit wurde quantitativ auf der Basis einer vergleichenden Modellrechnung qualitativ durch die systematische Erfassung zusätzlicher Vorteile geführt. Im Ergebnis zeigt sich eine beachtliches Wirtschaftlichkeitspotenzial zugunsten der konsortialen Softwareentwicklung! Hier noch einmal die wichtigsten Einsparungspotenziale zusammengefasst: Kürzere Entwicklungszeiten Verringerung der Inbetriebnahme-Aufwendungen Lizenzkosteneinsparungen Seite 17

18 Zusammenfassung der Machbarkeitsstudie Einsatz von Open-Source-Software ist auch in (kritischen) Industriebereichen bereits etabliert Technische Machbarkeit ist gegeben System- und Softwarearchitektur wurden hinreichend beschrieben Entwicklungswerkzeuge und -prozesse sind gegeben Organisatorische Machbarkeit ist gegeben Bildung einer Genossenschaft (kooperative Solidargemeinschaft) Abbildung des Ökosystems Wirtschaftlichkeit konnte qualitativ und quantitativ nachgewiesen werden Mit der gemeinschaftlichen Entwicklung von Open-Source-Software im Leitsystembereich besteht die Möglichkeit die Punkte Zeit, Qualität und Kosten der Softwareentwicklung zu verbessern und den Vendor-Lock-in zu überwinden. Seite 18

19 Agenda 1. Ausgangslage und Zielsetzung aus Sicht der Netzbetreiber 2. Ergebnisse der Machbarkeitsstudie 3. Vor- und Umsetzungsprojekt 4. Aktueller Stand 5. Fazit Seite 19

20 Roadmap Machbarkeitsstudie Vorprojekt Umsetzungsprojekt Zielsetzung: Prüfung der technischen Einsetzbarkeit von Open-Source- Software im Leitsystembereich Betrachtung der organisatorischen Umsetzbarkeit Grobe Abschätzung der Wirtschaftlichkeit Beachtung der üblichen Anforderungen für Leitsysteme (Verfügbarkeit, Sicherheit, Haftung etc.) Sept Jul Zielsetzung: Einbindung von Herstellern, wissenschaftlichen Instituten und Netzbetreibern Spezifikation zum Last- und Einspeisemanagement Kosten-/Nutzen-Verifizierung Konkretisierung System- und Softwarearchitektur sowie Entwicklungsumgebung Mögliche Geschäftsmodelle Prüfung weiterer Open- Source-Komponenten Zielsetzung: Umsetzung des organisatorischen Rahmens für die Anwender und Hersteller Umsetzung des Last- und Einspeisemanagements auf Open-Source-Basis Entwicklung weiterer Open- Source-Komponenten Weiterentwicklung des Konsortiums Sep Seite 20

21 Stand des Vorprojekts Aufgaben Stand Aufbau einer unternehmensübergreifenden Projektorganisation Veröffentlichung der Ergebnisse der Machbarkeitsstudie (Link siehe Anhang) Einbindung von Herstellern, wissenschaftlichen Instituten und Netzbetreibern Seite 21

22 Einbindung von Herstellern, Netzbetreibern und wissenschaftlichen Instituten Hersteller Insgesamt wurde mit 8 Leitsystemherstellern über die Überlegungen gesprochen 5 Hersteller nehmen zzt. aktiv an Gesprächen mit dem Ziel einer Angebotsabgabe teil 3 Hersteller befinden sich in einer beobachtenden Funktion Netzbetreiber Folgende 5 Netzbetreiber führen das Projekt aktiv Weitere Netzbetreiber haben Interesse signalisiert bzw. es werden Gespräche geführt Wissenschaftliche Institute Kontakt zu Hochschulen??? Seite 22

23 Stand des Vorprojekts Aufgaben Stand Aufbau einer unternehmensübergreifenden Projektorganisation Veröffentlichung der Ergebnisse der Machbarkeitsstudie (Link siehe Anhang) Einbindung von Herstellern, wissenschaftlichen Instituten und Netzbetreibern Unternehmensübergreifende Spezifikation Last- und Einspeisemanagement Konkretisierung der System- und Softwarearchitektur Seite 23

24 Modell Systemarchitektur Systemarchitektur mit der Schnittstelle an die hausinternen Systeme ist bei allen Anwendern erforderlich Module werden auf dem Application-Server betrieben Datenbank und Enterprise- Service-BUS (ESB) sollen möglichst auch unter Open- Source-Lizenzen laufen Auswahlverfahren ESB, Datenbank und App-Server über SWOT-Analyse erfolgt Seite 24

25 Stand des Vorprojekts Aufgaben Stand Aufbau einer unternehmensübergreifenden Projektorganisation Veröffentlichung der Ergebnisse der Machbarkeitsstudie (Link siehe Anhang) Einbindung von Herstellern, wissenschaftlichen Instituten und Netzbetreibern Unternehmensübergreifende Spezifikation Last- und Einspeisemanagement Konkretisierung der System- und Softwarearchitektur Konkretisierung der Entwicklungsumgebung Seite 25

26 Modell Entwicklungsumgebung Cloud Qualified Trusted Developers Integrator Commited Source Code Bug Reports CMS Specifikations Development Community d Seite 26

27 Modell Sicherheitszonen Angewendete Regelwerke BDEW Whitepaper Version 1.0 Anforderungen an sichere Steuerungsund Telekommunikationssysteme BDEW, Österreichs Energie Version 1.0 Sicherheitskatalog gem. 11 Abs. 1a EnWG (Entwurf) DIN 27001:2013, DIN 27002:2005, DIN SPEC April 2012 Seite 27

28 Stand des Vorprojekts Aufgaben Stand Aufbau einer unternehmensübergreifenden Projektorganisation Veröffentlichung der Ergebnisse der Machbarkeitsstudie (Link siehe Anhang) Einbindung von Herstellern, wissenschaftlichen Instituten und Netzbetreibern Unternehmensübergreifende Spezifikation Last- und Einspeisemanagement Konkretisierung der System- und Softwarearchitektur Konkretisierung der Entwicklungsumgebung Erarbeitung möglicher Geschäftsmodelle Kosten-/Nutzen-Verifizierung auf der Basis von Angeboten und Schätzkosten Seite 28

29 Kostenvergleich konventionelle zu Open-Source-Lösung Softwarebedarf Konventionelle Lösung* Open-Source-Lösung (KSE)* Projektphasen zur Softwareentwicklung Spezifikation und Lastenheft Ausschreibung u. Angebotsprüfung Aufbau Entwicklungsteam Pflichtenheft Überführung Lastenheft Softwareentwicklung Customizing Systemlieferant Prüfungen und Abnahmen Hardwarekosten Lizenzen und Systemkosten 10% der Lizenzkosten Aufwand je nach Projektgröße zwischen 5 und 10% der Lizenzsumme X Aufwandsreduzierung durch gemeinsame Arbeit; aber Mehraufwand durch Reibungsverluste Aufwand je nach Projektgröße; Spanne zwischen vollständigen Entfall und rd. 50 T Aufwandspauschale von ca. 10 T für Kommunikation und Verpflichtung Entwickler 10% der Lizenzkosten X X X Dienstleistung für projektspezifische Anpassungen; 10% der Lizenzkosten Anteilige Kosten Pflichtenheftphase konventionell; Aufwandsreduzierung und Reibungsverluste Aufwand nach Projektgröße 10% der Softwareentwicklungskosten 16 Projekttage a 500 und 2% der Lizenzkosten 8% der Softwareentwicklungskosten Beide Lösungen haben Kosten in gleicher Höhe; Kostenanteil bei Integration ins Hauptsystem Lizenzkosten abhängig von Projektgröße Beide Lösungen haben Kosten in gleicher Höhe; 10% der Entwicklungskosten X Wartungskosten 20% der Lizenzkosten 15% der Softwareentwicklungskosten * Annahmen auf Basis der Machbarkeitsstudie Consulectra Seite 29

30 Stand des Vorprojekts Aufgaben Stand Aufbau einer unternehmensübergreifenden Projektorganisation Veröffentlichung der Ergebnisse der Machbarkeitsstudie (Link siehe Anhang) Einbindung von Herstellern, wissenschaftlichen Instituten und Netzbetreibern Unternehmensübergreifende Spezifikation Last- und Einspeisemanagement Konkretisierung der System- und Softwarearchitektur Konkretisierung der Entwicklungsumgebung Erarbeitung möglicher Geschäftsmodelle Kosten-/Nutzen-Verifizierung auf der Basis von Angeboten und Schätzkosten Entwicklungsplanung durchführen Seite 30

31 Zukünftige Module Schnittstelle ESB Last- und Einspeisemanagement Visualisierung / GUI Stateestimation Lastfluss- und Kurzschlussstromberechnung Lastflussoptimierung Ausfallvariantenrechnung Niederspannungsnetzführung Energiemanagement Netzsicherheitsrechnung Engpassmanagement Gas Netzberechnung Gas Netzberechnung Fernwärme Schichttagebuch, Bereitschaftslisten Schaltantragsverwaltung Entstörungs- und Instandhaltungsmanagement Unterstützung mobiler Kräfte Mobile Erfassung technischer Daten Diverse GIS-Funktionalitäten Auswertung Betriebsmittelnutzung Krisenmanagement E-Mobility-Management Management-Informationssystem Störungsinformationstool App Versorgungsunterbrechungen Datenhaltung und visualisierung (Verbindung CIM) Netzberechnung Wasser Unterstützungstools (Formulare, Hilfen, ) Seite 31

32 Stand des Vorprojekts Aufgaben Stand Aufbau einer unternehmensübergreifenden Projektorganisation Veröffentlichung der Ergebnisse der Machbarkeitsstudie (Link siehe Anhang) Einbindung von Herstellern, wissenschaftlichen Instituten und Netzbetreibern Unternehmensübergreifende Spezifikation Last- und Einspeisemanagement Konkretisierung der System- und Softwarearchitektur Konkretisierung der Entwicklungsumgebung Erarbeitung möglicher Geschäftsmodelle Kosten-/Nutzen-Verifizierung auf der Basis von Angeboten und Schätzkosten Entwicklungsplanung durchführen Realisierungsplanung der Varianten des Umsetzungsprojekts Antragsstellung bei der Förderinitiative Zukunftsfähige Stromnetze Seite 32

33 Agenda 1. Ausgangslage und Zielsetzung aus Sicht der Netzbetreiber 2. Ergebnisse der Machbarkeitsstudie 3. Vor- und Umsetzungsprojekt 4. Aktueller Stand 5. Fazit Seite 33

34 Aktueller Stand, laufende Tätigkeiten Ein LOI ist von 5 Netzbetreibern unterzeichnet. Eine eclipse working group openkonseqenz ist in Gründung. Es folgen Workshops zum ESB (September) und GUI bzw. Style Guide (Oktober). Bis Ende September 2014 erarbeiten Hersteller Angebote für das erste Modul Last- und Einspeisemanagement. Im November entscheiden die Geschäftsführungen über die Art der Weiterführung des Konsortiums. Es wird kontinuierlich versucht, weitere Netzbetreiber für die Mitarbeit im Konsortium zu gewinnen. Seite 34

35 Agenda 1. Ausgangslage und Zielsetzung aus Sicht der Netzbetreiber 2. Ergebnisse der Machbarkeitsstudie 3. Vorprojekt 4. Weiteres Vorgehen 5. Fazit Seite 35

36 Fazit Erarbeitung der Machbarkeitsstudie konnte erfolgreich abgeschlossen werden und führt den Nachweis, dass die konsortiale Softwareentwicklung auf Basis von Open-Source-Software technisch / organisatorisch machbar und wirtschaftlich attraktiv ist Ansprache von Herstellern und Anwendern ist auf sehr positive Resonanz gestoßen weitere Akteure konnten im Vorprojekt hinzugewonnen werden Spezifikation Last- und Einspeisemanagement konnte unternehmensübergreifend erfolgreich abgeschlossen werden System- und Softwarearchitektur sowie Entwicklungsumgebung sind konkretisiert und mit den beteiligten Herstellern abgestimmt Geschäftsmodelle und Wirtschaftlichkeitsbetrachtungen sind ausgearbeitet Entwicklungsplanung für weitere Projekte und Module liegt vor Seite 36

37 Vielen Dank für Ihre Aufmerksamkeit! Michael Müller Abteilungsleiter Netzführung Netz Leipzig GmbH Seite 37

38 die Netz Leipzig gibt es jetzt auch als App! Gerade stromlos oder Heizung kalt? Informieren Sie sich per App Netz Leipzig (verfügbar in ios und Android) Entwickelt durch: TBZ Services GmbH Stefan Kosche Seite 38

39 Anhang Link zur Machbarkeitsstudie KONSEQUENZ Link zum Auftritt der eclipse working group openkonsequenz Seite 39