EVW-Phase 2 Das Projektteam

Transkript

1

2 Praxisimplementierung von zuverlässigkeits- und zustandsorientierten Betriebs- und Instandhaltungsstrategien auf Basis von standardisierten Prozessabläufen DIE VERANTWORTUNG FÜR DEN INHALT DIESER VERÖFFENTLICHUNG LIEGT BEI DEN AUTOREN EVW-Phase 2 Das Projektteam Das EVW Projektteam

3 ABSCHLUSSBERICHT Die Verantwortung für den Inhalt dieser Veröffentlichung liegt bei den Autoren. Projektkoordinator: IZP Dresden mbh Stauffenbergallee Dresden Vorhaben: EVW-Phase 2 Kennzeichen: D-H Verbundpartner: IZP Dresden mbh ENERTRAG AG Fraunhofer IWES, Kassel GEO Gesellschaft für Energie und Oekologie mbh WindStrom Erneuerbare Energien GmbH & Co. KG Kürzel im Bericht: IZP ENERTRAG IWES GEO WindStrom Unterauftragnehmer: FGW e.v. Fördergesellschaft Windenergie und andere Erneuerbare Energien Kürzel im Bericht: FGW

4 Inhalt ZUSAMMENFASSUNG KURZDARSTELLUNG AUFGABENSTELLUNG UND ZIELE VORAUSSETZUNGEN FÜR DIE PROJEKTDURCHFÜHRUNG PLANUNG UND ABLAUF DES VORHABENS STAND VON WISSENSCHAFT UND TECHNIK ZUM PROJEKTBEGINN TEILPROJEKTE DER PROJEKTPARTNER ENERTRAG Windstrom GEO als Projektpartner im Projektverbund EVW-Phase IZP Dresden mbh Fraunhofer IWES ZUSAMMENARBEIT MIT ANDEREN STELLEN DARSTELLUNG DER ERGEBNISSE STANDARDS UND RICHTLINIEN ZU INSTANDHALTUNGSDATEN Instandhaltung von Kraftwerken für Erneuerbare Energien (FGW TR7 Rubrik A) Zustands-Ereignis-Ursachen-Schlüssel für Erzeugungseinheiten Globales Service Protokoll Reference Designation System for Power Plants (RDS-PP ) AUFBAU UND BETRIEB DES WIND-POOL Datenumfang und verwendete Standards Vertraulichkeitskonzept Reporting und Zuverlässigkeitskennwerte Anwendungsfelder und Nutzen Kooperationsvereinbarung Datenbankmodell Datenfluss, Import und Mapping Technische Umsetzung Aktueller Stand und Ausblick METHODEN UND ANWENDUNGSSZENARIEN FÜR SYSTEMANALYSEN Zuverlässigkeitsbewertungen LCC (Life Cycle Costs) RCM Gefährdungsanalysen Wissensdatenbank Anforderungen an die Datenbasis aus statistischer Sicht Beispielanalysen TEST- UND DEMONSTRATIONSSYSTEM Instandhaltungsprozess und beispielhafter Informationsfluss Modul Leitwarte SCADA-Viewer Modul Instandhaltungsdatenmanagement CMMS Mobile Datenerfassung Service Engineer Industrieimplementierung REGAS Zusammenfassung und Ausblick PRAXISIMPLEMENTIERUNG IN DEN UNTERNEHMEN Ziele, aktueller Stand und Potentiale Implementierung von ZEUS bei GEO WIS-Datenexport zum WInD-Pool bei GEO Implementierung von ZEUS und RDS-PP bei ENERTRAG Implementierung von GSP bei WindStrom ÖFFENTLICHKEITSARBEIT/ WISSENSVERBREITUNG Projektbeirat Gremienarbeit Publikationen Abschlussbericht EVW Phase

5 2.6.4 Vorträge Projektwebseite AUSBLICK ERREICHTER STAND PROJEKTSKIZZE WEA.WIND-POOL STANDARDS UND RICHTLINIEN ZU INSTANDHALTUNGSDATEN ANLAGEN ERGEBNISSE GEFÄHRDUNGSANALYSE - GUTLÄUFERUNTERSUCHUNGEN Auswertung von ENERTRAG-Daten Auswertung von EVW-Daten Analyseergebnisse Gutläuferuntersuchungen mit 1 Ereignis Ereignis nach 4 Jahren Betriebszeit Ereignis nach 18 Jahren Betriebszeit AUFSTELLUNG WEITERER SEPARATER ANLAGEN ZUM ABSCHLUSSBERICHT: Tabellenverzeichnis TABELLE 1: ANWENDUNGSFÄLLE FÜR DAS GLOBALE SERVICEPROTOKOLL TABELLE 2: ZUSAMMENFASSUNG DES MINIMALDATENKATALOGS DES WIND-POOL ENTSPRECHEND ANLAGE B DER KOOPERATIONSVEREINBARUNG ZUM WIND-POOL TABELLE 3: EINSATZPOTENZIAL DER RCM-ANALYSEMETHODE BEI GEGENWÄRTIGEN MARKTBEDINGUNGEN TABELLE 4: ZUSAMMENGEFASSTE ERGEBNISSE DER GUTLÄUFERANALYSE TABELLE 5: STAMM- UND EREIGNISDATEN FÜR DEN EXPORT ZU WIND-POOL TABELLE 6: TREFFEN DES PROJEKTBEIRATS AM STANDORT DES FRAUNHOFER IWES IN KASSEL TABELLE 7: IM PROJEKTBEIRAT DES EVW-PROJEKTES PHASE 2 ENGAGIERTE UNTERNEHMEN TABELLE 8: VORTRÄGE AUF MESSEN, SEMINAREN UND KONFERENZEN TABELLE 9: ZUVERLÄSSIGKEITSKENNGRÖßEN EREIGNIS ROTORBLATTBRUCH AUF BASIS ENERTRAG-DATEN TABELLE 10: ZUVERLÄSSIGKEITSKENNGRÖßEN EREIGNIS ROTORBLATTBRUCH AUF BASIS EVW-DATEN TABELLE 11: ZUVERLÄSSIGKEITSKENNGRÖßEN 1 FIKTIVER ROTORBLATTBRUCH NACH 1 JAHR AUF BASIS ENERTRAG-DATEN TABELLE 12: ZUVERLÄSSIGKEITSKENNGRÖßEN 1 FIKTIVER ROTORBLATTBRUCH NACH 4 JAHREN AUF BASIS ENERTRAG-DATEN TABELLE 13: ZUVERLÄSSIGKEITSKENNGRÖßEN 1 FIKTIVER ROTORBLATTBRUCH NACH 18 JAHREN AUF BASIS ENERTRAG-DATEN Abbildungsverzeichnis ABBILDUNG 1: PROJEKTTEILNEHMER IM VERBUNDVORHABEN EVW-PHASE ABBILDUNG 2: ZEITGLEICH MIT DER WEITERENTWICKLUNG DER ANLAGENTECHNIK HABEN SICH DIE AUSFALLRATEN VIELER HAUPTKOMPONENTEN ERHÖHT... 9 ABBILDUNG 3: KOMMUNIKATION ZWISCHEN DEN VERSCHIEDENEN PARTEIEN IM BETRIEB UND DER INSTANDHALTUNG VON WEA ABBILDUNG 4: IM EVW-PROJEKT BETRACHTETES NORMENWERK FÜR DEN BEREICH WINDENERGIE ABBILDUNG 5: MANUELLE UND KLASSIERTE INSTANDHALTUNGSDOKUMENTATION IN DER PRAXISANWENDUNG ABBILDUNG 6: AUFBAU DES ZEUS-SCHLÜSSELS ABBILDUNG 7: INFORMATIONSBLÖCKE IM ZEUS-SCHLÜSSELSATZ (OHNE ANGABE DER ZÄHLNUMMER UND OHNE KENNWERTE) ABBILDUNG 8: SPRACHUNABHÄNGIGKEIT DER ZEUS-SCHLÜSSELCODIERUNG ABBILDUNG 9: RELEVANTE MERKMALE AUS DEM ZEUS-SCHLÜSSELSATZ FÜR DEN ANWENDUNGSFALL ANLAGENBEGEHUNG ABBILDUNG 10: ANWENDUNGSFELDER UND VORTEILE DES GSP ABBILDUNG 11: ERGEBNISSE EINER UMFRAGE DES ARBEITSKREIS GSP DER FGW E.V. ZUR NOTWENDIGKEIT UND VERFÜGBARKEIT VON DATEN IN DER BETRIEBSPHASE VON WEA ABBILDUNG 12: MUSTERPROZESS, WELCHER IN DIE ENTWICKLUNG DES GSP EINFLOSS (GEM. TR7 RUBRIK D3 ABSCHNITT 3.8) ABBILDUNG 13: IT-PROZESSABLAUF (GEM. TR7 RUBRIK D3 REV. 0 ABSCHNITT 3.9) ABBILDUNG 14: AUFBAU DES GSP DATENAUSTAUSCHFORMATES ABBILDUNG 15: HAUPTKLASSEN IM XML-SCHEMA DES GSP ABBILDUNG 16: ANLAGENKENNZEICHNUNG NACH DIN EN FÜR EIN ENERGIEVERSORGUNGSSYSTEM ABBILDUNG 17: AUSWERTUNG VON INSTANDHALTUNGSDATEN NACH RDS-PP BETRIEBSMITTELKENNZEICHEN ABBILDUNG 18: GRUNDPRINZIP DES WIND-POOL Abschlussbericht EVW Phase

6 ABBILDUNG 19: VERTRAULICHKEITSKONZEPT DES WIND-POOL ENTSPRECHEND ANLAGE A DER KOOPERATIONSVEREINBARUNG ZUM WIND-POOL ABBILDUNG 20: AUTOMATISIERTE ERSTELLUNG UND VERTEILUNG ANONYMISIERTER AUSWERTUNGEN AUF BASIS DES WIND-POOL ABBILDUNG 21: ANWENDUNGSFELDER DES WIND-POOL MIT FOKUS AUF BETRIEB- UND INSTANDHALTUNG VON WEA ABBILDUNG 22: AUFBAU DER KOOPERATIONSVEREINBARUNG ZUM WIND-POOL ABBILDUNG 23: STARK VEREINFACHTE DARSTELLUNG DES DATENBANKSCHEMAS DES WIND-POOL ABBILDUNG 24: ABLAUF ZUR INTEGRATION WEITERER DATENLIEFERANTEN IN DEN WIND-POOL ABBILDUNG 25: SCHEMATISCHE DARSTELLUNG DER TECHNISCHEN KONZEPTION DES WIND-POOL ABBILDUNG 26: ZUVERLÄSSIGKEITSSCHALTBILD EINES 2-AUS-3 SYSTEMS ABBILDUNG 27: FEHLERBAUM FÜR EIN 2-AUS-3 SYSTEM ABBILDUNG 28: STANDARDISIERTER FEHLERBAUM EINES 2-AUS-3-SYSTEMS ABBILDUNG 29: SICHERHEITSAUSLEGUNG BEIM BESCHLEUNIGUNGSSENSOR GAM900S ALS SYSTEM MIT KOMPLEXEM SCHALTBILD ABBILDUNG 30: BETRIEBSVARIANTEN EINES K-AUS-N-SYSTEMS IM ANALYSETOOL ABBILDUNG 31: MARKOW-GRAPH ABBILDUNG 32: COMMON CAUSE FAILURE ABBILDUNG 33: PRINZIPSCHALTBILD GENERATORKÜHLUNG ABBILDUNG 34: VORSCHLAG FÜR WEA-LCC-BASISSTRUKTUR ABBILDUNG 35: AUSZUG AUS FMEA-STRUKTUR ALS BASIS FÜR DETAILLIERUNG DER KORREKTIVEN KOSTEN ABBILDUNG 36: SIMULIERTE KOSTENPROGNOSE FÜR WEA-TEILSYSTEME ABBILDUNG 37: RCM-ENTSCHEIDUNGSDIAGRAMM ABBILDUNG 38: NUTZENEFFEKTE IM MODERIERTEN RCM-ANALYSEVERFAHREN NACH MOUBRAY ABBILDUNG 39: SIMULATION MÖGLICHER EINSCHLÄGE ABGELÖSTER ROTORBLATTEILE (QUELLE: ENERTRAG AG, DAUERTHAL) ABBILDUNG 40: WORKFLOW RAMS-OFFICE NG ABBILDUNG 41:BAUMSTRUKTUR DER EVWII-WISSENSDATENBANK (KENNWERTEBIBLIOTHEK = KWB) ABBILDUNG 42: EINZELSATZANSICHT IN DER KWB ABBILDUNG 43: DARSTELLUNG DER LEBENSDAUERGRAFIKEN IN DER KWB ABBILDUNG 44: EINFLUSS DES STICHPROBENUMFANGS AUF DIE SCHÄTZUNG EINES ANTEILSWERTES ABBILDUNG 45: EINFLUSS DES STICHPROBENUMFANGS AUF DIE SCHÄTZUNG EINER VERTEILUNGSFUNKTION ABBILDUNG 46: EINFLUSS DER GESAMTTESTDAUER AUF DIE SCHÄTZUNG EINER FEHLERHÄUFIGKEIT ABBILDUNG 47: ÜBERBLICK ZU AUSGEWÄHLTEN RAMS/LCC-METHODEN ABBILDUNG 48: OLAP FÜR WIND-POOL DATENBANK ABBILDUNG 49: KORREKTIVE INSTANDHALTUNGSMAßNAHMEN PRO ANLAGE UND MONAT MIT MEHR ALS 0,5 TAGEN STILLSTANDSZEIT. 89 ABBILDUNG 50: ERZEUGUNGSVERLUSTE PRO MONAT UND ANLAGE DURCH KORREKTIVE INSTANDHALTUNGEN ABBILDUNG 51: MITTLERE EREIGNISDAUER BEI KORREKTIVEN INSTANDHALTUNGEN PRO MONAT ABBILDUNG 52: MITTLERE DAUER KORREKTIVER INSTANDHALTUNGEN PRO RDS-PP EBENE ABBILDUNG 53: VERTEILUNGSVERGLEICH EXPONENTIAL- UND WEIBULLVERTEILUNG ABBILDUNG 54: AUSGEWÄHLTE ZUVERLÄSSIGKEITSKENNWERTE MIT KONFIDENZGRENZEN (KG) ABBILDUNG 55: VERTEILUNGSVERGLEICH KORREKTIVE INSTANDHALTUNG ZWISCHEN ANLAGENTYPEN EINES HERSTELLERS ABBILDUNG 56: VERGLEICH DER ERWARTUNGSWERTE FÜR KORREKTIVE INSTANDHALTUNGSEREIGNISSE BEI VERSCHIEDENEN ANLAGENHERSTELLERN ABBILDUNG 57: VERTEILUNGSVERGLEICH FÜR RDS-PP EBENE ABBILDUNG 58: TECHNISCHE VERFÜGBARKEIT UND ENERGIEERTRAG ABBILDUNG 59: VERFÜGBARKEITSBETRACHTUNG MITTELS FEHLERBAUMANALYSE ABBILDUNG 60: AUSFALLWAHRSCHEINLICHKEIT FÜR TEILSYSTEM ABBILDUNG 61: ANZAHL KORREKTIVE MAßNAHMEN PRO JAHR FÜR 100 ANLAGEN ABBILDUNG 62: OPTIMALES INSTANDHALTUNGSINTERVALL FÜR AUSGEWÄHLTES ANLAGENTEILSYSTEM ABBILDUNG 63: AUFBAU DES TEST- UND DEMONSTRATIONSSYSTEMS ABBILDUNG 64: GROBE DARSTELLUNG DES INFORMATIONSFLUSSES IM TEST- UND DEMONSTRATIONSSYSTEM ABBILDUNG 65: AUSWERTUNG DER MARKTRECHERCHE ZU SCADA-SOFTWARE BASIEREND AUF 23 PRODUKTEN ABBILDUNG 66: FUNKTIONSUMFANG DES SCADA-VIEWER UND AUFTEILUNG IN NUTZEROBERFLÄCHE UND HINTERGRUNDFUNKTIONALITÄTEN ABBILDUNG 67: ÜBERSICHT DER NUTZEROBERFLÄCHE DES SCADA-VIEWER ABBILDUNG 68: SICHTEN DES SCADA-VIEWER ZU DEN DATEN EINER EINZELNEN WEA ABBILDUNG 69: PRÄSENTATION DER DATENAUSWERTUNG IM SCADA-VIEWER ABBILDUNG 70: BENUTZEROBERFLÄCHE DES MODULS INSTANDHALTUNGSMANAGEMENT - CMMS ABBILDUNG 71: DETAILDARSTELLUNG DES SOLL-PROZESSES FÜR DIE DURCHFÜHRUNG DER INSTANDHALTUNGSMAßNAHMEN DURCH DAS SERVICE-PERSONAL ABBILDUNG 72: HAPTISCHE ANFORDERUNGEN AN EINE MDE-SOFTWARE-BENUTZEROBERFLÄCHE Abschlussbericht EVW Phase

7 ABBILDUNG 73: BENUTZEROBERFLÄCHE EINES UNTER WINDOWS 7 UMGESETZTEN PROTOTYPS ZUR MOBILEN DATENERFASSUNG ABBILDUNG 74: VERGLEICH VON HERKÖMMLICHER UND TOUCHOPTIMIERTER OBERFLÄCHE FÜR EINEN TABLET-PC (WINDOWS DEMONSTRATOR; AUSZUG AUS DER ZEUS-DATENERFASSUNG) ABBILDUNG 75: ANSICHTEN DER BENUTZEROBERFLÄCHE ZUR MOBILEN DATENERFASSUNG UNTER ANDROID ABBILDUNG 76: ANLAGENSTRUKTUR NACH RDS-PP IN REGAS FÜR EINEN WEA-TYP ABBILDUNG 77: PRAXISIMPLEMENTIERUNG REGAS PRÜFBAUSTEINE EINER KONFORMITÄTSPRÜFUNG INKL. ANWENDUNG VON ZEUS ABBILDUNG 78: TOOL ZUR ZUWEISUNG VON ZEUS-EINTRÄGEN ZU EREIGNISSEN ABBILDUNG 79: WEITERE TOOLS ZUM DATENTRANSFER ABBILDUNG 80: ANWENDERSPEZIFISCHE OLAP-ANALYSE ABBILDUNG 81: ANWENDERSPEZIFISCHER VERTEILUNGSVERGLEICH FÜR AUSGEWÄHLTE TEILSYSTEME ABBILDUNG 82: HINZUFÜGEN VON ZEUS-EREIGNISSEN IN STATUSCODES ABBILDUNG 83: NEUE SPALTE ZEUS IN DER STATUSCODELISTE ABBILDUNG 84: HINZUFÜGEN/BEARBEITEN VON ELEMENTEN EINES ZEUS-EREIGNISSES ABBILDUNG 85: TABELLENANSICHT ZEUS ABBILDUNG 86: ÜBERSICHT WIS SYSTEMAUFBAU ABBILDUNG 87: EXPORT VON DATEN AUS WIS ÜBER XML-DATEI ABBILDUNG 88: DAS FORMULAR FÜR ZEUS INSPEKTIONSPROTOKOLLE IM POWERSYSTEM ABBILDUNG 89: DIE ZUORDNUNG VON ZEUS INSPEKTIONSPROKOTOLLEN ZU ENERGIEANLAGEN ABBILDUNG 90: DAS MAPPING ZWISCHEN RDS-PP UND BAUGRUPPENKLASSIFIZIERUNG ABBILDUNG 91: DIE RDS-PP KENNZEICHNUNG WIRD BEI EINER STÖRUNG UNTEN AUTOMATISCH ANGEZEIGT ABBILDUNG 92: EIN GSP ARBEITSSAUFTRAG AN EXTERNE INSTANDHALTER ABBILDUNG 93: EIN GSP ARBEITSAUFTRAG AN DEN HAUSEIGENEN INSTANDHALTER ABBILDUNG 94: STRUKTUR DER EVW-PROJEKTWEBSEITE ABBILDUNG 95: NUTZEN DES WIND-POOL ÜBER DIE LEBENSZYKLUSPHASE EINER WEA ABBILDUNG 96: ZUVERLÄSSIGKEITSFUNKTION EREIGNIS ROTORBLATTBRUCH AUF BASIS ENERTRAG-DATEN ABBILDUNG 97: VERTEILUNGSFUNKTION EREIGNIS ROTORBLATTBRUCH AUF BASIS ENERTRAG-DATEN ABBILDUNG 98: DICHTEFUNKTION EREIGNIS ROTORBLATTBRUCH AUF BASIS ENERTRAG-DATEN ABBILDUNG 99: AUSFALLRATE EREIGNIS ROTORBLATTBRUCH AUF BASIS ENERTRAG-DATEN ABBILDUNG 100: ZUVERLÄSSIGKEITSFUNKTION EREIGNIS ROTORBLATTBRUCH AUF BASIS EVW-DATEN ABBILDUNG 101: VERTEILUNGSFUNKTION EREIGNIS ROTORBLATTBRUCH AUF BASIS EVW-DATEN ABBILDUNG 102: DICHTEFUNKTION EREIGNIS ROTORBLATTBRUCH AUF BASIS EVW-DATEN ABBILDUNG 103: AUSFALLRATE EREIGNIS ROTORBLATTBRUCH AUF BASIS EVW-DATEN ABBILDUNG 104: ZUVERLÄSSIGKEITSFUNKTION 1 FIKTIVER ROTORBLATTBRUCH NACH 1 JAHR ABBILDUNG 105: VERTEILUNGSFUNKTION 1 FIKTIVER ROTORBLATTBRUCH NACH 1 JAHR ABBILDUNG 106: DICHTEFUNKTION 1 FIKTIVER ROTORBLATTBRUCH NACH 1 JAHR ABBILDUNG 107: AUSFALLRATE 1 FIKTIVER ROTORBLATTBRUCH NACH 1 JAHR ABBILDUNG 108: ZUVERLÄSSIGKEITSFUNKTION 1 FIKTIVER ROTORBLATTBRUCH NACH 4 JAHREN ABBILDUNG 109: VERTEILUNGSFUNKTION 1 FIKTIVER ROTORBLATTBRUCH NACH 4 JAHREN ABBILDUNG 110: DICHTEFUNKTION 1 FIKTIVER ROTORBLATTBRUCH NACH 4 JAHREN ABBILDUNG 111: AUSFALLRATE 1 FIKTIVER ROTORBLATTBRUCH NACH 4 JAHREN ABBILDUNG 112: ZUVERLÄSSIGKEITSFUNKTION 1 FIKTIVER ROTORBLATTBRUCH NACH 18 JAHREN ABBILDUNG 113: VERTEILUNGSFUNKTION 1 FIKTIVER ROTORBLATTBRUCH NACH 18 JAHREN ABBILDUNG 114: DICHTEFUNKTION 1 FIKTIVER ROTORBLATTBRUCH NACH 18 JAHREN ABBILDUNG 115: AUSFALLRATE 1 FIKTIVER ROTORBLATTBRUCH NACH 18 JAHREN Abschlussbericht EVW Phase

8 Zusammenfassung Zusammenfassung Im diesem Bericht werden die grundlegenden des vom Bundesministerium für Wirtschaft und Energie geförderten Verbundprojektes Erhöhung der Verfügbarkeit von Windenergieanlagen Phase 2 (EVW-PHASE 2). dargestellt. Verbundpartner im Projekt waren IZP Dresden mbh, ENERTRAG Windstrom GmbH, WindStrom Betriebs- & Verwaltungs- GmbH, Fraunhofer IWES, GEO mbh. Als Unterauftragnehmer war die Fördergesellschaft Windenergie FGW mit eingebunden. Grundlegendes Ziel des Vorhabens war laut Projektantrag vom Praxisimplementierung von zuverlässigkeitsund zustandsorientierten Betriebs- und Instandhaltungsstrategien auf Basis von standardisierten Prozessabläufen. Die ursprüngliche Laufzeit des Projektes laut Zuwendungsbescheid vom war für den Zeitraum vom bis geplant. Auf Grund von nicht durch das Projektkonsortium zu beeinflussende Praxisverzögerungen wurde eine kostenneutrale Verlängerung bis zum beantragt und vom BMWi genehmigt. Die Projektkoordination erfolgte durch die IZP Dresden mbh. Jeder Projektpartner war für die Bearbeitung seines eigenen Teilprojektes in Abstimmung mit den anderen Partnern voll eigenverantwortlich zuständig. Beantragt wurde das Projekt innerhalb der Bekanntmachung über die Förderung von Forschung und Entwicklung im Bereich erneuerbare Energien vom 20. November Basis der Arbeiten in EVW-PHASE 2 waren die des Vorgängerprojektes EVW I. Hier wurden die methodischen Grundlagen gelegt und die ersten Schritte hin zur standardisierten Datenerfassung in der Instandhaltung von Windenergieanlagen gelegt (siehe auch Abbildung 1: Projektteilnehmer im Verbundvorhaben EVW-PHASE 2 Innerhalb des Projektarbeit gliederte sich in folgende Arbeitspakete: 1. Projektkoordination, Gremien- und Öffentlichkeitsarbeit 2. Entwicklung technischer Lösungen und Standards 3. Test und Demonstration des Gesamtsystems 4. Betriebliche Einführung infrastruktureller Voraussetzungen 5. Analysen, Kennwerte, IH-Strategien, Offshore Einsatz 6. Implementierung von optimierten Betriebs- und Instandhaltungsstrategien Abschlussbericht EVW Phase

9 Zusammenfassung Alle Arbeitspakete konnten erfolgreich bearbeitet werden. Aus Gründen, die im Bericht noch näher erläutert werden, mussten jedoch teilweise Schwerpunktverlagerungen vorgenommen werden. Dies betraf insbesondere die direkte Einführung konkreter Betriebs- und Instandhaltungsstrategien. Eine solche Implementierung war leider im Projekt noch nicht möglich, weil die vorhandene Datenbasis noch nicht repräsentativ ist und damit noch keine abgesicherten Entscheidungen zulässt. Es ist aber gelungen, weitere Interessenten für den WInD-Pool zu gewinnen.. Ein weiteres Problem der Praxis war die unzureichende Bereitstellung von Informationen zu konkreten Instandhaltungskosten. Solche Daten liegen aktuell hauptsächlich nur beim Anlagenhersteller vor oder werden wegen ihrer Sensibilität noch nicht bereitgestellt. Ohne Informationen zu Instandhaltungs- und Ausfallfolgekosten ist eine Instandhaltungsoptimierung aber nur bedingt durch Hinzunahme von Expertenabschätzungen möglich. Aber auch hier gibt es erste positive Signale, die zukünftig eine verbesserte Aufnahme von Kostendaten erwarten lassen. Die Abstriche im Bereich der Strategieeinführung konnten aber durch andere Praxisaktivitäten erfolgreich ausgeglichen werden. So wurde z.b. unter Nutzung der geschaffenen EVW-Datenbasis eine Gefährdungsanalyse durchgeführt. Diese hat wesentlich zur Beschleunigung der Standortgenehmigung für einen neuen Windpark beigetragen. Der neue Anwendungsfall der unternehmensübergreifenden Datenbasis hat gezeigt, dass der WInD-Pool noch viele weitere Praxispotentiale in sich vereint. Der avisierte Standardisierungsprozess für die Informationserfassung konnte weitestgehend abgeschlossen werden. Die Mitglieder des EVW-Konsortiums waren federführend bei der Einführung der Standards ZEUS und GSP, die im Bericht ausführlich beschrieben werden. Außerdem wurden erste praxiswirksame Lösungen zur Anwendung dieser Standards bei Betriebsführungsunternehmen des EVW-Verbundes eingeführt. Auch bei der Erarbeitung des VGB-Standards RDS-PP haben Mitglieder aus dem EVW-Projekt mitgewirkt. Als weitere wichtige Aktivitäten bzw. des Projektes sind zu nennen: Untersuchungen und Pilotlösungen zur mobilen Datenerfassung Implementierung einer Wissensdatenbank Durchführung von Beispielanalysen Intensive Öffentlichkeitsarbeit Aufbau eines Test-und Demonstrationssystems. Grundlage für den hohen Praxisbezug des Projektes war insbesondere die Arbeit mit dem Projektbeirat. Hier konnten viele namhafte Firmen der Branche für eine teilweise oder dauerhafte Mitarbeit gewonnen werden. Über dieses Gremium wurden alle Ziele und Resultate permanent auf den Praxisprüfstand gestellt. Der im Antrag formulierte Bezug zu den besonderen Anforderungen des Offshore-Betriebs wurde insbesondere durch die enge Abstimmung mit dem Offshore-WMEP sichergestellt. Aber auch im Projektbeirat und bei Tagungen wurden Offshore-Aspekte diskutiert und in das Lösungskonzept eingebracht. Zentrales praxiswirksames Ergebnis ist der sich nun im Betrieb befindliche WInD-Pool. Der auf ORACLE-Basis durch Fraunhofer IWES betriebene Datenbankserver wird zukünftig vielfältige Analysen ermöglichen. Konkrete Fragestellungen dazu liegen bereits von einigen Unternehmen vor. Der Datenaufbereitungsprozess ist für die einzelnen Datenlieferanten aber momentan noch mit hohem manuellem Aufwand verbunden. Abschlussbericht EVW Phase

10 Kurzdarstellung 1 Kurzdarstellung 1.1 Aufgabenstellung und Ziele Die im Projektantrag formulierte Aufgabenstellung der Phase 2 des praxisorientierten EVW- Verbundprojektes lautete: Ziel des geplanten FuE-Vorhabens ist es daher, die zuverlässigkeitsorientierte Instandhaltung, die in Unternehmen der Luftfahrt, der Automobilbranche u.a. Branchen bereits Anwendung findet, auch in der Windenergiebranche einzuführen. Datenbankgestützte Analysen zielgerichtet erfasster Informationen bieten belastbares Zahlenmaterial für das Ermitteln von Schwachstellen und kostentreibenden Abläufen und damit Entscheidungshilfen für dringend erforderliche Verbesserungsmaßnahmen. Die Leistungsfähigkeit der Windenergieanlagen (WEA) hat sich in den vergangenen zwei Dekaden sowohl aus technischer als auch aus ökonomischer Sicht erheblich verbessert. Der kontinuierliche Ausbau der Windenergienutzung ermöglichte den Herstellern gezielte Weiterentwicklungen der Anlagentechnik zur Steigerung von Effizienz und Performance der Anlagen. Wie intensive und umfassende Analysen früherer Forschungsvorhaben aber zeigen, steht dem eine abnehmende Zuverlässigkeit moderner Windenergieanlagen und ihrer Bauteile gegenüber (siehe Abbildung 2, Quelle: WMEP). Annual failure rate. Abbildung 2: Zeitgleich mit der Weiterentwicklung der Anlagentechnik haben sich die Ausfallraten vieler Hauptkomponenten erhöht Die Organisation von Betriebsüberwachung und Instandhaltung machte es zum Zeitpunkt der Antragstellung wie in Kapitel 2.4 beschrieben nahezu unmöglich, die vielfältigen Erfahrungen aus dem Betrieb der Anlagen gezielt für Verbesserungen zu nutzen. Ziel des FuE-Vorhabens war es daher, die zuverlässigkeitsorientierte Instandhaltung auch in der Windenergiebranche einzuführen. Wesentliche Voraussetzungen für dieses Vorhaben wurden schon in dem vom Bundesministerium für Umwelt, Naturschutz und Reaktorsicherheit geförderten Projekt Erhöhung der Verfügbarkeit von Windenergieanlagen (EVW) geschaffen. Um die in diesem Projekt gewonnenen Erkenntnisse und entwickelten Konzepte sowie Teillösungen möglichst schnell in die Praxis einführen zu können, war eine zeitnahe und intensive Fortführung der Arbeiten notwendig. Dazu sollten bedarfsgerechte Dienstleistungsangebote sowie einsatzreife Soft- und Hardware-Produkte geschaffen werden. In Zusammenarbeit mit der Fördergesellschaft Windenergie und andere Erneuerbare Energien e.v. (FGW) und anderen Gremien der Windenergiebranche sollten die entwickelten Verfahren und Datenstrukturen in Form von Technischen Richtlinien als Branchenstandard eingeführt werden. Mit der vorgesehenen Imple- Abschlussbericht EVW Phase

11 Kurzdarstellung mentierung eines durchgängigen Demonstrations- und Testlabors sollte die Basis für eine breite Praxisnutzung der gelegt werden. Mit dem Vorhaben wurden im Wesentlichen die folgenden Ziele verfolgt: Entwicklung von Standards und Strukturen zur einheitlichen Erfassung, Übermittlung und Speicherung von Betriebs- und Instandhaltungsdaten (u.a. im Rahmen von Gremienarbeit) Aufbau eines Test- und Demonstrationssystems zur Abbildung eines durchgängigen Informationsflusses im Instandhaltungsprozess von WEA Test verschiedener Hard- und Softwarevarianten im Test- und Demonstrationssystem sowie die Einbindung der Softwarelösungen der beteiligten Betriebsführer sowie dritter Unternehmen. Anpassung des Instandhaltungsdatenmanagements der Beteiligten Betriebsführer/Betreiber unter Berücksichtigung der existierenden/entwickelten Industriestandards. Aufbau einer unternehmensübergreifenden Datenbank mit Stamm-, Betriebs- und Ereignisdaten der am Projekt beteiligten Betreiber/Betriebsführer. Analyse der im gemeinsamen Datenpool gesammelten Daten hinsichtlich Zuverlässigkeitskennwerten und Instandhaltungsstrategien Ein weiterer Punkt der Aufgabenstellung war die Berücksichtigung von Besonderheiten der Offshore- Windenergieerzeugung. 1.2 Voraussetzungen für die Projektdurchführung Das Projekt konnte sich auf die bereits vorhandenen der Phase I des EVW-Fördervorhabens stützen. Da die Partner bereits teilweise in diesem Vorgängerprojekt erfolgreich zusammengearbeitet hatten, konnte der notwendige Kooperationsvertrag zeitnah erstellt werden. Das Projektkonsortium aus den Firmen IZP Dresden mbh, ENERTRAG Windstrom GmbH, WindStrom Betriebs- & Verwaltungs- GmbH, Fraunhofer IWES, GEO mbh und der FGW bildete eine gute Kombination aus Betriebsführungsunternehmen, Forschungseinrichtungen und einem Branchenverband. Durch die Gründung eines Projektbeirates wurden zusätzlich auch Hersteller von Anlagen und Komponenten, Serviceunternehmen, Versicherungen und Unternehmen aus anderen Bereichen der Windbranche einbezogen. Dadurch konnte ein ganzheitlicher Systemansatz unter Berücksichtigung möglichst vieler Interessen sichergestellt werden. Abschlussbericht EVW Phase

12 Kurzdarstellung 1.3 Planung und Ablauf des Vorhabens Die Planung des Vorhabens basierte auf dem im Antrag erstellten Arbeits- und Zeitplan. Die Koordinierung aller Aktivitäten wurde durch die IZP Dresden mbh übernommen. Als Arbeitspakete wurden bearbeitet: 1. Projektkoordination, Gremien- und Öffentlichkeitsarbeit 2. Entwicklung technischer Lösungen und Standards 3. Test und Demonstration des Gesamtsystems 4. Betriebliche Einführung infrastruktureller Voraussetzungen 5. Analysen, Kennwerte, IH-Strategien, Offshore Einsatz 6. Implementierung von optimierten Betriebs- und Instandhaltungsstrategien Der Projektfortschritt und die Inhalte aller Teilarbeiten wurden durch regelmäßige Partnertreffen abgesichert und kontrolliert. Diese Treffen fanden im Wechsel bei den einzelnen Unternehmen des Konsortiums statt. Der Projektbeirat hat zu einer zusätzlichen Praxiskontrolle des Projektablaufes beigetragen. Über die Internetplattform des Projektes war und ist das Projekt für die allgemeine Öffentlichkeit jederzeit zugänglich. Durch nicht zu beeinflussende Praxisprobleme musste jedoch eine kostenneutrale Verlängerung um ein Jahr beantragt werden. Gründe für diese Verzögerung waren: 1. Verzögerungen und Abstimmungsprobleme im Standardisierungsprozess 2. Aufwändige Klärung lizenzrechtlicher Probleme bei der Anwendung von Standards, Normen und Richtlinien 3. Praxistest der im Projekt entwickelten Standards hat gezeigt, dass individuelle Anpassungen bezüglich Prozessen, technischen Teilsystemen und Ingenieurbereichen notwendig sind 4. Umstrukturierung und Verlagerung von Verantwortlichkeiten bei einzelnen Projektpartnern 5. Erhöhter Argumentationsbedarf (zeitlich - längere Entscheidungshorizonte) zur Gewinnung von Datenverbundpartnern 6. Operative Umsetzung der Standards bei Betreibern aufwendiger als geplant, daher Verzögerungen bei anderen Projektpartnern 7. Heterogene Soft- und Hardwarebasis bei den Verbundpartnern und Praxisinteressenten 8. Bei Betreibergesellschaften des Projektverbunds sind Entwicklungskapazitäten durch die Erweiterung des Direktvermarktungsanteils und die Einführung des Fernsteuerbonus gebunden wurden Trotz der zeitlichen Verzögerung konnten aber alle wesentlichen Ziele mit gewissen Schwerpunktverlagerungen erreicht werden. Abschlussbericht EVW Phase

13 Kurzdarstellung 1.4 Stand von Wissenschaft und Technik zum Projektbeginn Die Untersuchungen und Arbeiten im Rahmen der ersten Phase des Projektes "Erhöhung des Verfügbarkeit von Windenergieanlagen" hatten gezeigt, dass die Informationsverarbeitung und das Instandhaltungsmanagement in der Windbranche zum Zeitpunkt der Projektbeantragung in unternehmensindividuellen Prozessen ohne einheitliche Strukturen und Kodierungssysteme erfolgte. Auch hinsichtlich der Zuverlässigkeit und Verfügbarkeit von Windenergieanlagen bestand Verbesserungspotential, welches bei Weitem noch nicht ausgeschöpft war. Die schnelle technologische Entwicklung und der kurze Marktlebenszyklus führten mitunter zu unausgereiften Produkten und unvollständigen bzw. unzureichenden Betriebs- und Instandhaltungskonzepten. Erkenntnisse aus dem Betrieb der WEA konnten nur bedingt in der sich schnell entwickelnden Branche berücksichtigt werden. Gründe dafür sind u.a. in der unzureichenden Konkurrenzsituation und der teilweisen Monopolstellung von Anlagenherstellern zu sehen. Gleichzeitig war die Windbranche durch eine hohe Zahl von Akteuren geprägt, ohne dass einheitliche Festlegungen zur Kommunikation existierten. Es war daher zum einen eine Öffnung der Hersteller hinsichtlich einer besseren und transparenteren Zusammenarbeit mit den anderen Akteuren der Windbranche, insbesondere in Bezug auf den Betrieb- und die Instandhaltung von WEA, zum anderen aber auch verbesserte Kommunikation und Kooperation zwischen allen Akteuren der Windbranche notwendig. Die in Phase I des EVW-Projekts beispielhaft für einen Anlagentyp durchgeführte Fehlermöglichkeitsund Einflussanalyse (FMEA) hat zahlreiche potentielle Schwachstellen und Verbesserungsansätze für die WEA-Technik aufgedeckt. Zur Identifizierung tatsächlich im Betrieb auftretender Schwachstellen bestimmter Anlagenkonzepte oder Anlagentypen fehlte jedoch eine ausreichend umfangreiche Datenbasis zu statistischen Absicherung entsprechender Untersuchungen. Eindeutige Erkenntnis aus der ersten Phase des EVW-Projektes war daher, dass sich notwendige Aussagen für die Instandhaltungsoptimierung sowie die Verbesserung der WEA-Technik nur anhand einer umfangreichen Sammlung an Betriebserfahrung inkl. Schadensdaten treffen lassen. Zwar existierten zu Beginn des Projektes bereits mehrere Datensammlungen, wie die des Wissenschaftliche Mess- und Evaluierungsprogramm WMEP", der LWK, von Windstats, VTT und oder Elforsk, diese Initiativen beschränkten sich jedoch zum Großteil auf die Erfassung von Schadensdaten und waren in ihrem Detailgrad aufgrund fehlender Standards limitiert. Insbesondere das Thema fehlender Standards zur Beschreibung von Ereignissen und Fehlern an WEA bzw. der betroffenen Komponenten war zum Zeitpunkt des Projektbeginns noch nicht gelöst. Zwar lag zum Projektbeginn beispielsweise schon eine erste Anwendungserläuterung des Reference Designation System for Power Plants (RDS-PP ) des VGB Power Tech zur einheitlichen Beschreibung der einzelnen Komponenten und Funktionen von WEA vor, diese wies für viele Anwendungsfälle aber noch Unklarheiten auf und war in der Branche nicht akzeptiert. Selbige Situation existierte bei der Beschreibung und Klassifizierung von Ereignissen/Fehlern. Das existierende Ereignis-Merkmal-Schlüsselsystem (EMS) des VGB für konventionelle Kraftwerke hatte sich als für die Windindustrie ungeeignet herausgestellt. Zwar wurde in der ersten Phase des Projektes EVW eine Anpassung des EMS an die Bedürfnisse der Windbranche durchgeführt, jedoch keine zufriedenstellende Lösung gefunden. Ein weiteres Hemmnis zur einheitlichen und systematischen Erfassung der Betriebserfahrung von WEA lag im Fehlen geeigneter Werkzeuge, z.b. zur komfortablen Dokumentation von Instandhaltungsmaßnahmen oder Inspektion von WEA durch Sachverständige. Auch die Softwaresysteme der Betriebsführungsunternehmen waren auf die Aufnahme entsprechender Daten, insbesondere unter Einsatz von Standards, nicht oder nur begrenzt vorbereitet. Gleiches gilt für den Austausch von Instandhaltungsdokumentationen zwischen verschiedenen am Instandhaltungsprozess beteiligten Akteuren. Ein einheitlicher Standard zum Datenaustausch existierte nicht. Berichte wurden in Papierform, per PDF und im besten Falle per Excel zur Verfügung gestellt. Das Haupthindernis zur Umsetzung der in der ersten Phase des EVW-Projektes erarbeiteten Methoden lag daher bei der sehr uneinheitlichen und teilweise mangelhaften Informationsbasis bei den zu integrierenden Unternehmen. Dies kann nun mit den im EVW-Projekt geschaffenen Informationsstandards Abschlussbericht EVW Phase

14 Kurzdarstellung gezielt überwunden werden. Zentrales Ziel der zweiten Phase des Projektes war es, eine einheitliche Informationsbasis für die Anwendung der Zuverlässigkeitsorientierten Instandhaltung (ZIH) zu schaffen. 1.5 Teilprojekte der Projektpartner Für das Erreichen der oben genannten Ziele haben die Projektpartner in unterschiedlichem Umfang einzelne Teilaufgaben bzw. Arbeitsschwerpunkte übernommen. Nachfolgend wird zunächst ein kurzer Einblick in das Profil der beteiligten Unternehmen gegeben, und deren Anteil innerhalb des EVW2 Projektes im Überblick dargestellt ENERTRAG Die ENERTRAG AG ist ein auf Nachhaltigkeit spezialisiertes europäisches Energieunternehmen, das Strom ausschließlich aus erneuerbaren Quellen produziert hauptsächlich aus Windenergie. ENER- TRAG vereint heute mit 400 Mitarbeitern europaweit alle Kompetenzen, die für ein erfolgreiches Betreiben von Windenergieanlagen und für die Erzeugung und Lieferung erneuerbarer Energie notwendig sind. Von der Planung, Technologieentwicklung und Finanzierung über den Bau und die Betriebsführung bis zur Einspeisung in das eigene Stromnetz mit dazugehörigen Umspannwerken und europaweitem Anschluss ist ENERTRAG eines der wenigen Unternehmen weltweit, das jedes notwendige Glied in der Produktionskette von nachhaltiger Windenergie bedient. Als unabhängiger Servicedienstleister bietet ENERTRAG zusätzlich ein umfangreiches Servicenetzwerk für Windkraftanlagen von Partnerunternehmen. Im Verbundprojekt EVW-Phase 2 übernahm ENERTRAG in Zusammenarbeit mit den Verbundprojektpartnern folgende Aufgaben: Erweiterung einer Betriebsführungs-Datenbank um RDS-PP Erweiterung einer Betriebsführungs-Datenbank um ZEUS Bereitstellung von Betriebsdaten aus zahlreichen Windparks für die Projektpartner Windstrom ENERTRAG WindStrom GmbH wurde 2011 als Zusammenschluss der Betriebsführungsbereiche der Unternehmen ENERTRAG und WindStrom WSBV gegründet, um den Kunden ein noch umfassenderes Leistungsportfolio bieten zu können und die Kompetenzen zweier starker Partner zu bündeln. Das Unternehmen sieht sich als Impulsgeber mit jahrzehntelanger Erfahrung im Betrieb von Windkraftwerken, der Unternehmen auf ihrem Weg der Energiewende partnerschaftlich und professionell begleitet. Im Verbundprojekt EVW-Phase 2 übernahm WSBV in Zusammenarbeit mit den Verbundprojektpartnern folgende Aufgaben: Erweiterung einer Betriebsführungs-Datenbank um GSP Bereitstellung von Betriebsdaten aus zahlreichen Windparks für die Projektpartner Abschlussbericht EVW Phase

15 Kurzdarstellung GEO als Projektpartner im Projektverbund EVW-Phase 2 Die GEO, Gesellschaft für Energie und Ökologie mbh, aus Nordfriesland besitzt über 15 Jahre Erfahrung in der umfassende Leistungspalette von der Planung, Beratung über den Verkauf bis hin zur zertifizierten technischen Betriebsführung und Ertragsoptimierung von Windenergieprojekten. Damit ein Windpark auf die Dauer zuverlässig funktioniert, muss er kontinuierlich überwacht und betreut werden. GEO übernimmt die professionelle technische Betriebsführung um höchste Verfügbarkeit, fehlerfreie Abläufe und somit maximale Erträge zu gewährleisten. Die kontinuierliche Überwachung und Betreuung der Windenergieanlagen ist die Grundlage für langfristige Werterhaltung und wirtschaftlichen Erfolg. GEO erfüllt mit seiner technischen Betriebsführung höchste Qualitätsstandards. Regelmäßige Prüfungen zur Rezertifizierung gemäß DIN EN ISO 9001:2008 weisen das erfolgreich nach. In der technischen Betriebsführung der GEO mbh werden - kontinuierlich von über 50 Windparks an 365 Tagen im Jahr - rund um die Uhr sämtliche Daten von den Windenergieanlagen ausgelesen und in einer eigenen Datenbank gespeichert. Folgerichtig hat GEO sich im Verbundprojekt EVW-Phase 2 in erster Linie mit dem Arbeitspaket Datenerhebung der Betriebsparameter von modernen Windenergieanlagen befasst. Zudem hat GEO in Zusammenarbeit mit den Verbundprojektpartnern an weiteren Aufgaben mitgewirkt. Bearbeitet bzw. mitgearbeitet hat GEO insgesamt folgende Aufgabenbereiche: Aufbau einer automatischen Datenerfassung sämtlicher online eingehenden Betriebs- und Instandhaltungsdaten aus den unterschiedlichen Anlagensteuerungen in eine einheitliche Betriebsführungsdatenbank (WIS-Datenbank) Entwicklung einer Datenverarbeitung und -aufbereitung in eine einheitliches Format zur Nutzbarmachung von Onshore-Daten zum Aufbau von Offshore-Fachwissen (ZEUS-Modul) Schaffung einer abgestimmte Datenexport-Schnittstelle zur Integration der Betriebs- und Instandhaltungsdaten in eine gemeinsame Datenbankstruktur WInD-Pool (Datenexport WInD-Pool) Mitwirkung bei der Schaffung des Referenzkennzeichensystem Reference Designation System for Power Plants (RDS-PP ) Mitarbeit bei der Optimierung des Zustands-Ereignis-Ursachen-Schlüssels (ZEUS) Mitwirkung bei der Entwicklung des einheitlichen Globales-Service- Protokolls (GSP) Abschlussbericht EVW Phase

16 Kurzdarstellung IZP Dresden mbh Die Ingenieurgesellschaft für Zuverlässigkeit und Prozessmodellierung Dresden mbh ist ein branchenübergreifend tätiges Ingenieurdienstleistungsunternehmen im Bereich des Zuverlässigkeits- und Kostenmanagements. Dabei werden Analysen, Beratungen, Schulungen und Softwarelösungen im Umfeld er RAMS/LCC -Technologie angeboten. Die in der mehr als 18 jährigen Tätigkeiten gewonnen Erkenntnisse aus anderen Branchen konnten auch für das EVW-Projekt genutzt wurden. Die Aufgabenstellung für das von der IZP zu bearbeitende Teilprojekt lautete: Aufbau einer RAMS/LCC-Wissensdatenbank und Implementierung von Methoden und Werkzeugen für ein zuverlässigkeitsorientiertes Betriebs- und Instandhaltungsmanagement. Diese Aufgabe konnte in enger Zusammenarbeit mit allen Partnern und insbesondere mit dem IWES erfolgreich bearbeitet werden. Im Projekt wurde eine Musterlösung für eine Wissensdatenbank erstellt und mit dem WInD-Pool gekoppelt. Außerdem wurden vorhandene Modelle zur Modellierung und Optimierung von Instandhaltungsprozessen an die Projekterfordernisse angepasst und erweitert. Darüber hinaus wurden spezielle Softwarelösungen für die halbautomatisierte Datenaufbereitung entwickelt. Diese konnten bereits bei der Datenübertragung aus der EVW I-Datenbank und bei der Neueinspielung von Partnerdatenquellen erfolgreich getestet werden. Das seit vielen Jahren bei führenden Unternehmen im Einsatz befindliche RAMS/LCC-Werkzeug der IZP - RAMS-Office NG wurde im Projekt so weiterentwickelt, dass es sich nun direkt mit der WInD-Pool Datenbank verbinden lässt und so vielfältige Spezialanalysen ermöglicht. RAMS-Office NG konnte so auch als wichtige Basis für die durchgeführten Beispielanalysen genutzt werden. Weitere Aufgaben und Aktivitäten der IZP im Rahmen des Projektes waren: Koordinierung der Projektaktivitäten Beratung und Schulung der Verbundpartner zur Anwendung der RAMS/LCC-Technologie Federführung bei der Erarbeitung der Richtlinien ZEUS und GSP Unterstützung bei der Strukturierung und Optimierung der WInD-Pool Datenbank Grundlagenarbeiten zur LCC-Strukturierung von Windenergieanlagen Durchführung einer Gefährdungsanalyse im Zusammenhang mit einer Standortgenehmigung für einen neuen Windpark Öffentlichkeitsarbeit in Form von Vorträgen und Veröffentlichungen Mitarbeit bei der Gestaltung der Internet-Plattform des Projektes Abschlussbericht EVW Phase

17 Kurzdarstellung Fraunhofer IWES Als praxisorientiertes und unabhängiges Forschungsinstitut übernimmt das Fraunhofer-Institut für Windenergie und Energiesystemtechnik, kurz Fraunhofer IWES, im Verbundprojekt EVW-Phase 2 folgende in Zusammenarbeit mit den Verbundprojektpartnern folgende Aufgaben: Betreuung des Projektbeirates, Pflege der Projekthomepage sowie generelle Außendarstellung Entwicklung von Standards und Strukturen zur einheitlichen Erfassung, Übermittlung und Speicherung von Betriebs- und Instandhaltungsdaten im Rahmen der Gremienarbeit Entwicklung eines Test- und Demonstrationssystems zur Untersuchung und Veranschaulichung des Datenflusses im Betrieb und der Instandhaltung von Windenergieanlagen unter Verwendung einer standardisierten Kommunikation Aufbau und Betrieb des Windenergie-Informations-Daten-Pool (WInD-Pool) als unternehmensübergreifenden Erfahrungsdatenbasis Die hierzu notwendigen Arbeiten sind im Teilprojekt Entwicklung und Aufbau eines Test- und Demonstrationssystems zur Datenerfassung, -übertragung und -speicherung von Betriebs- und Instandhaltungsdaten als Grundlage für eine zuverlässigkeitsorientierte Instandhaltung (TDS-ZIH) zusammengefasst. Der Schwerpunkt des Teilprojektes liegt auf der Entwicklung des Test- und Demonstrationssystems und dem Aufbau des WInD-Pool. Als Unterauftragnehmer des Fraunhofer IWES unterstützt die Fördergesellschaft Windenergie und andere Erneuerbare Energien e. V. (FGW) die Arbeit des Projektkonsortiums. Das Aufgabenspektrum der FGW reicht von der Unterstützung bei der generellen Außendarstellung bis zur Übernahme der Projektergebnisse in die Richtlinien und Standardisierungsarbeit. Die wesentlichen Aufgaben der FGW sind nachfolgend aufgelistet. Öffentlichkeitsarbeit zur Bekanntmachung der der Projektergebnisse in der Windbranche inkl. Pflege der Projektwebseite Vorstellung und Präsentation des Verbundprojektes auf Messen, Kongressen und anderen Veranstaltungen der Windbranche. Vernetzung der Projektpartner mit der Windbranche, insbesondere den Mitgliedern der FGW z.b. im Fachausschuss Instandhaltung Erweiterung der Technischen Richtlinien 7 Betrieb und Instandhaltung von Kraftwerken für Erneuerbare Energien unter Berücksichtigung der Projektergebnisse und als Grundlage für den einheitlichen Austausch von Instandhaltungsdaten. Abschlussbericht EVW Phase

18 Kurzdarstellung 1.6 Zusammenarbeit mit anderen Stellen Im Rahmen der Projektlaufzeit wurde die Zusammenarbeit mit mehreren Verbänden, Institutionen und Unternehmen aufgenommen bzw. intensiviert. Nachfolgend soll hierzu ein kurzer Überblick gegeben werden. VGB PowerTech e.v. Eine Zusammenarbeit mit dem VGB erfolgte u.a. durch die Gremienarbeit mit Rahmen der Überarbeitung der Anwendungsrichtlinie zum RDS-PP für die Windenergie. Darüber hinaus erfolgte eine Abstimmung mit dem VGB über eine mögliche Zusammenarbeit in Bezug auf die Datenerfassung des EVW-Projektes im WInD-Pool und die Initiative des VGB zukünftig WEA in die KISSY- Kraftwerksstatistik aufzunehmen. Erklärtes Ziel ist eine Kompatibilität der Datenbasen, so dass interessierte Unternehmen detaillierte Informationen in den WInD-Pool einspielen können und diese dann in aggregierter Form auch in die KISSY-Statistik fließen. Eine formelle Übereinkunft über die Zusammenarbeit wurde bisher nicht abgeschlossen. Offshore~WMEP(FKZ: A) Das vom Fraunhofer IWES durchgeführte Projekt Offshore~WMEP hat neben dem Monitoring der Windenergienutzung auch den Aufbau einer Betriebs- und Schadensdatenbank für Offshore-WEA zur Aufgabe. Vor diesem Hintergrund erfolgte zwischen beiden Projekten eine enge Abstimmung, so dass u.a. das Datenbankdesign und die verwendeten Methoden zur Betriebsdatenauswertung kompatibel sind. Langfristiges Ziel ist die Zusammenführung der Datenbasen für Onshore- und Offshore-WEA. Über das Offshore~WMEP wurden auch des EVW-Projektes im Task 33 Reliability Data der IEA Wind platziert. Arbeitskreise des Fachausschuss Instandhaltung (FAIH) der FGW Zur Fertigstellung der im Projekt benötigten Richtlinien haben die Projektpartner eng mit dem FAIH und der FGW zusammengearbeitet und sich u.a. in den Arbeitskreisen GSP und ZEUS engagiert. Projekt EUMONIS/Institut für Angewandte Informatik e. V. an der Universität Leipzig Während der Projektbearbeitung hat sich herausgestellt, dass es mit dem vom Bundesministerium für Bildung und Forschung BMBF geförderten Projekt EUMONIS (FKZ: 01IS10033C) zwar keine Überschneidungen in der Zielsetzung gibt, beide Projekte jedoch auf die Verwendung einheitlicher Standards bzgl. der Erfassung und Weitergabe von Instandhaltungsdaten angewiesen sind. Vor diesem Hintergrund fanden mehrfach Abstimmungsgespräche statt und die Fertigstellung des GSP wurde gemeinsam intensiv vorangetrieben. Abschlussbericht EVW Phase

19 Darstellung der 2 Darstellung der Entsprechend der in Kapitel 1.1 beschriebenen Teilziele des Projektes erfolgt in den nachfolgenden Kapiteln eine Darstellung der Projektergebnisse. 2.1 Standards und Richtlinien zu Instandhaltungsdaten Wie Abbildung 3 zeigt, sind am Betrieb und der Instandhaltung von WEA eine Vielzahl an Parteien beteiligt, zwischen denen ein der Austausch von Informationen/Daten erforderlich ist. Während es für die Erfassung und Übertragung von Betriebsdaten beispielsweise mit dem IEC-Standard einen einheitlichen Standard und einheitliche Bezeichnungen für die verschiedenen auftretenden Daten gibt, war dies für Instandhaltungsdaten zu Projektbeginn nicht der Fall bzw. waren die zu diesem Zeitpunkt verfügbaren Richtlinien nicht für die Anwendung in der Windbranche geeignet. Abbildung 3: Kommunikation zwischen den verschiedenen Parteien im Betrieb und der Instandhaltung von WEA Um Instandhaltungsdaten einheitlich erfassen zu können, müssen im Wesentlichen drei Voraussetzungen erfüllt werden. Erstens bedarf es einer einheitlichen und typübergreifenden Bezeichnung von Systemen der WEA und den einzelnen Komponenten um ein einheitliches Verständnis zu erreichen. Darüber hinaus müssen sich die an einer WEA aufgetretenen Ereignisse, die daraus resultierenden Zustände und daraufhin ergriffenen Maßnahmen einheitlich kategorisieren lassen. Nicht zuletzt bedarf es einer klar definierten Schnittstelle zum Austausch von Auftrags- und Berichtsinformationen, in der die beschriebene einheitliche Sprache verwendet wird. Die hierzu notwendigen Standards und Richtlinien sind nachfolgend beschrieben. Abschlussbericht EVW Phase

20 Darstellung der Instandhaltung von Kraftwerken für Erneuerbare Energien (FGW TR7 Rubrik A) Im Sinne der DIN EN und der DIN umfasst die Instandhaltung (IH) alle technischen und administrativen Maßnahmen sowie das Management der Maßnahmen, die zur Erkennung des Ist- Zustandes, zur Erhaltung des funktionsfähigen Zustandes, zur Rückführung in diesen und zur Steigerung der Funktionssicherheit während des Lebenszyklus einer Einheit benötigt werden. Ziel einer ordnungsgemäßen Instandhaltung ist es, den Wert des investierten Kapitals und die geforderte Verfügbarkeit sicherzustellen sowie die öffentliche Sicherheit zu schützen. Jeder Betreiber einer Anlage ist für den sicheren und wirtschaftlichen Betrieb verantwortlich. Er ist für Schäden an der Umwelt oder an Personen, die durch die von ihm betriebenen Erzeugungseinheiten oder der dazugehörigen Infrastrukturen unmittelbar verursacht werden, haftbar. Es ist deshalb nicht nur aus wirtschaftlichen Erwägungen notwendig, den Betrieb möglichst lückenlos und ausreichend für Behörden, Versicherungen und Banken zu dokumentieren. Diese Dokumentation dient neben Sicherheitsaspekten auch der Priorisierung, Planung und Steuerung von Instandhaltungsmaßnahmen sowie der Analyse der Betriebs- und Instandhaltungsdaten hinsichtlich der Fortschreibung der laufenden Instandhaltungsplanung, der Optimierung der genannten Prozesse sowie zur Verbesserung der Anlagen. Der Betreiber benötigt dazu alle erforderlichen technischen Unterlagen entsprechend DIN EN Eine standardisierte Gestaltung der Dokumentation und Datenschnittstellen erleichtert die Zusammenarbeit aller Prozessbeteiligten. Um die komplexen Kommunikationsaufgaben im Bereich der Instandhaltung zu lösen, war es notwendig, normative Vereinbarungen zu treffen. Ziel der Normierung bzw. der Abgabe von Richtlinien war: das Instandhaltungsmanagement auf eine verifizierbare Datenbasis für Entscheidungen stützen zu können mit einer effektiven Datenerfassung eine Grundlage für Benchmarks und übergreifende Auswertungen zu sichern die Informationsverluste an den Schnittstellen zwischen Akteuren und Systemen zu minimieren. Hierzu wurden in Fortsetzung der geleisteten Arbeit im Projekt EVW Phase 1 in Phase 2 drei Standardisierungsaufgaben einbezogen: die Kennzeichnung der Anlagen die klassierte Beschreibung von Zuständen und Ereignissen die Schaffung eines IT-system unabhängigen Standards zur Übertragung von Instandhaltungsdaten und im Rahmen der Instandhaltung benötigter Informationen Ergebnis dieser Bemühungen ist, dass am Ende der Phase 2 des Projektes EVW zwei anwendbare, ja bereits angewendete Richtlinien unter maßgeblicher Beteiligung des EVW-Projektteams erarbeitet wurden, welche zusammen mit der Richtlinie zur Anlagenkennzeichnung des VGB eine gute Ausgangsbasis für die Datenerfassung und Auswertung im Bereich Instandhaltung bilden. Abschlussbericht EVW Phase

21 Darstellung der Abbildung 4: Im EVW-Projekt betrachtetes Normenwerk für den Bereich Windenergie In den folgenden Abschnitten soll auf die Standards und deren erste Anwendungserfahrungen eingegangen werden. Abschlussbericht EVW Phase

22 2.1.2 Zustands-Ereignis-Ursachen-Schlüssel für Erzeugungseinheiten Darstellung der Der Zustands-Ereignis-Ursachen-Schlüssel für Erzeugungseinheiten (ZEUS) ist eine maßgeblich im Rahmen des Forschungsprojektes EVW entwickelte Codierung für Instandhaltungsrelevante Informationen. Der Schlüssel ist in der Richtlinie FGW TR7 Rubrik D2 normiert, welche bei Projektende bereits in der Erstüberarbeitung der Revision 1 vorlag Funktionen und Nutzen Der ZEUS-Schlüssel übernimmt im IH-Managementsystem folgende Funktionen: Herstellung einer einheitlichen Sprachregelung zur Entscheidungsunterstützung im Instandhaltungsmanagement auf der Basis empirischer, verifizier- und operationalisierbarer Auswertungsprozesse Zur Erreichung dieses Zieles: Klassierte Bezeichnung für den Zustand der Anlage und ihrer Elemente in der Systemstruktur für die Prozessphasen Überwachung, Überprüfung und Instandhaltungsaktivität (z.b. Instandsetzung durch Reparatur) Manuelle IH- Dokumentation Klassierte Beschreibung von IH-relevanten Informationen in Kategorien Abbildung 5: Manuelle und klassierte Instandhaltungsdokumentation in der Praxisanwendung Abschlussbericht EVW Phase

23 Darstellung der Mit ZEUS wurde eine branchenweit einheitliche Sprachebene geschaffen, die als standardisierte unternehmensweite sowie unternehmensübergreifende Kommunikations- und Dokumentationsbasis für alle Zustandsbeschreibungen und Zustandsänderungen von Erzeugungseinheiten genutzt werden kann. Mit der Einführung des ZEUS-Schlüssels ist die Hoffnung auf Realisierung folgender Nutzeffekte verbunden: Vermeidung missverständlicher Interpretationen von Basisdaten Erhöhung der Effizienz bei der Prozessdatenverarbeitung und des Prozessmonitorings Fehlervermeidung und Reduzierung redundanter Arbeiten im Informationsverarbeitungsprozess Sicherstellung einer verifizierbaren und damit auch rechtssicheren Technik- und Prozessdokumentation Mittelfristige Senkung des Datenerfassungsaufwandes durch standardisierte Abläufe Aufbau eines bereichs- und unternehmensübergreifenden Benchmark-Systems ermöglichen Haptische Vorteile für die mobile Datenerfassung durch Verringerung des Aufwandes für tastaturgestützte Eingabe von Langtexten Aufbau des ZEUS-Schlüssels Aufbau des ZEUS-Schlüssels 1. Zifferngruppe (02) Betrachtungsobjekttyp ist Element (Block 2) 2. Zifferngruppe (05) Informationsblock zur Ausfallursache 3. Zifferngruppe (02) Untermerkmal ist Ursache außerhalb Energieanlage 4. Zifferngruppe (04) Detailangabe: Ausfallursache ist Sturm Abbildung 6: Aufbau des ZEUS-Schlüssels Der ZEUS-Schlüssel besteht aus hierarchisch in einer Baumstruktur gegliederten Zahlencodierung (ZEUS-Code) und einem zugeordneten Beschreibungstext der jeweiligen Anwendungssprache. Hierarchisch gegliedert bedeutet: Für jede Informationseinheit auf der letzten Codierungsebene (im Beispiel Gliederungsstufe 4, d.h. 4. Zifferngruppe) sind alle übergeordneten Informationscodes (Gliederungsstufe 1-3) genau zutreffend. Die höheren Gliederungsstufen stellen also die Kategorien dar, in denen die ZEUS-Informationseinheit eingeordnet werden kann (hier Sturm als externe Ausfallursache für ein Element). Abschlussbericht EVW Phase

24 Hierbei werden unterschieden: Darstellung der 2 Ziffern (ZEUS Block 01 und 02), welcher die Zählnummer des Betrachtungsobjekttyps angibt (Anlage/Element) Zifferngruppen 2 bis 6 für die hierarchisch gegliederte Zustandsbeschreibung mit o o o Zifferngruppe 2: Zählnummer des Informationsblocks für den Betrachtungsobjekttyp Zifferngruppe 3: Zählnummer des Untermerkmales Zifferngruppe 4-6: Zählnummer der beschreibenden Detailinformationen Zusätzlich zu den bislang 12 Informationsblöcken für die Elemente und den 4 Informationsblöcken zum Anlagenzustand sieht der Schlüssel die Möglichkeit zur Übermittlung von ZEUS-Kennwerten vor. Und zwar: Leistungsdaten der Anlage zum Erfassungszeitpunkt Bewertungszahlen für einen Anlagen- und Elementzustand. Abbildung 7: Informationsblöcke im ZEUS-Schlüsselsatz (ohne Angabe der Zählnummer und ohne Kennwerte) Abschlussbericht EVW Phase

25 Darstellung der Bei der Festlegung der Kriterien und Beschreibungstexte wurde die im Instandhaltungsbereich übliche Begriffswelt, die sich in den Definitionen DIN EN wiederfindet, herangezogen. Deutsch Englisch Französisch Abbildung 8: Sprachunabhängigkeit der ZEUS-Schlüsselcodierung Anwendung des ZEUS-Schlüssels Die Anwendung des ZEUS-Schlüssels ist in der ZEUS-Richtlinie nicht geregelt, d.h. die Richtlinie definiert im Wesentlichen den Aufbau und die Codierungsmöglichkeiten mit dem ZEUS-Schlüssel, nicht aber dessen Anwendung im IH-Prozess. Dies wäre auch nicht sinnvoll, da die Prozesse in den Unternehmen unterschiedlich ausgestaltet sind. Im Zuge der Implementierung sind folgende Punkte zu beachten, damit die Nutzeffekte einer klassierten Zustandsbeschreibung erreicht werden können: Die Anwendung im Prozess ist Sache der Implementierung des IH-Dokumentationsprozesses, wofür ein mehr oder weniger einheitliches Vorgehen wünschenswert ist. Ob dafür im Rahmen einer Richtlinie (z.b. TR 7 Rubrik C Dokumentation oder einer anderen Richtlinie). Die Datenübermittlung ist Aufgabe der IT-Implementierung zur Umsetzung der IH- Dokumentation. Hier wurde das Globale Serviceprotokoll entsprechend zur Übertragung von ZEUS-Statusinformationen befähigt (siehe Kapitel 2.1.3). Die Strukturierung des Systems, d.h. die Frage für welche Elemente bis zu welcher Gliederungstiefe ZEUS-Informationen im Block 2 erfasst werden sollen, ist Sache der Anlagendokumentation durch den Hersteller bzw. Betreiber. Hier steht mit RDS-PP (vgl. Abschnitt 2.1.4) ein Kennzeichensystem zur Verfügung, welches auch im Globalen Serviceprotokoll übertragen werden kann. Als sinnvoll erachtet wird eine Strukturierung unterhalb von RDS-PP bis zur kleinsten tauschbaren Einheit (handelsübliches Ersatzteil). Auch dies ist bei Anwendung des GSP darstellbar. Erst wenn diese Punkte geklärt wurden ist es möglich, dem an der IH beteiligten Personal den Nutzen und die Anwendung von ZEUS so darzulegen, dass eine Akzeptanz erreicht werden kann. Die Spezifizierung eines IT-nahen Datenerfassungsprozesses in der Instandhaltung und der Analyse der Informationsanforderungen für die einzelnen Anwendungsfälle ermöglichst es zudem, die notwendigen Eingaben auf ein Minimum zu reduzieren. Für eine übergreifende Datenauswertung sind die aus den jeweiligen Prozessschritten eingehenden Informationen so aufzubereiten, dass eine Vergleichbarkeit mit anderen Prozesslandschaften gegeben ist (z.b. Zusammenstellung von Informationen für ein zuverlässigkeitsrelevantes Ereignis in einer Zuverlässigkeitsdatenbank). Abschlussbericht EVW Phase

26 Dies kann z.b. erreicht werden durch: die Definition von Rollen für die Anwendungsfälle im IH-Prozess der Unternehmen Darstellung der die logische Verknüpfung von ZEUS-codierten Informationen (z.b. Fehlermeldung von der Anlage führt automatisch zur Generierung einer zutreffenden ZEUS-codierten Statusinformation in der Überwachung) Prozess- und Anwendungsfallgeführte Vorlage der Auswahlmöglichkeiten für den Benutzer (z.b. mögliche Abweichungen vom Sollzustand anhand RDS-PP-Kennzeichen des Elementes festlegen) Bisherige Erfahrungen und Ausblick Erste Implementierungserfahrungen zeigen, dass die Einführung des ZEUS-Schlüssels einen wichtigen Beitrag für eine strukturierte und damit nach logischen bzw. sachlichen Gesichtspunkten verifizierbare IH-Dokumentation leisten kann. Außerdem ist der Aufwand zur Migration in die IT-Systeme überschaubar. Dem gegenüber steht allerdings ein erheblicher Aufwand der Einführung in die tatsächlich gelebten Prozesse, der vor allem durch eine präzise Bearbeitung der im vorangegangenen Abschnitt genannten Punkte entsteht. Die Anwendung von ZEUS ist also kein Selbstläufer, noch darf sie natürlich ein Selbstzweck sein. Wie die im Projekt gemachten Implementierungserfahrungen (s. Kapitel 2.5) zeigen, ist es vor allem dann sinnvoll, die Anwendung der ZEUS-Codierung zu favorisieren, wo im Rahmen der Notwendigkeit für Prozessänderungen eine Möglichkeit zur Anpassung der Informationsverarbeitung besteht. Anstöße für solche Änderungen in der Praxis sind, wenn die bisherigen Erfahrungen im Projekt reflektiert werden insbesondere zu sehen in: ungenügende Informationsqualität der vorhandenen Daten Wechsel des Modus der Zusammenarbeit im Bereich der IH, z.b. durch neue Serviceverträge, Vertragspartner oder der Einführung des elektronischen Datenaustausches Die Notwendigkeit der Migration unterschiedlicher IT-Systeme Leider kollidiert das Ziel einer besseren Datenqualität häufig mit Befürchtungen, dass diese Nachteile für die eigene Wettbewerbsposition durch eine höhere Transparenz schafft und/oder zu ungerechtfertigtem Mehraufwand bei der Implementierung der Datenerfassung führt. Aus den o.g. Gründen blieb die Anwendung von ZEUS bislang weitgehend auf die unternehmensinterne Datenerfassung mit einfachen Anwendungsfällen (wie etwa dem Bereich Anlagenüberwachung bei GEO) beschränkt. Als nicht immer einfach erwies es sich im Projekt, die unterschiedlichen Sprachregelungen und das Sprachverständnis der unterschiedlichen Gewerke, Rollen und Qualifikationsgrade des Personals in Einklang zu bringen. Da Fachnormen meist von akademisch ausgebildeten Ingenieuren bzw. im Bereich der Gutachter auch verwaltungs- und baurechtlichem Hintergrund erarbeitet werden, ist es nicht selbstverständlich, dass das IH-Personal diese Definitionen durchgängig kennt und deren in ZEUS übernommene Abgrenzung im Normenwerk (z.b. der DIN EN 13306) auch intuitiv versteht. Auch zwischen Gutachtern, Ingenieuren und Kaufleuten herrscht nicht immer dasselbe Definitionsverständnis. Teilweise gibt es auch andere, in den Unternehmen historisch gewachsene Sprachregelungen. Die Erfahrung zeigte hier, dass nur eine gute Schulung und Vermittlung der Motivation für die Nutzung der ZEUS-Codierung, als auch das ergänzende Angebot von fachlicher Unterstützung (z.b. durch Hilfetexte in der Erfassungssoftware) die notwendige Akzeptanz bei den verantwortlichen Mitarbeitern aufbaut. Nach einer Einarbeitungszeit gab es jedoch im Praxiseinsatz kaum noch Probleme. Abschlussbericht EVW Phase

27 Darstellung der Neben der Verständlichkeit abgeleiteter Normdefinitionen, ist bei einer Weiterentwicklung des Standards das Augenmerk auch auf die unterschiedlichen Gewerke zu legen: Elektrotechnik, Steuer- und Messtechnik, Bautechnik usw. haben unterschiedliche Bedürfnisse. Dies betrifft insbesondere die Beschreibung der Instandhaltungstätigkeit (02-09), als auch die Primäre Abweichung vom Sollzustand, vereinfacht gesagt also das Mängel- oder Schadbild (02-12). Um den Erfassungsaufwand zu verringern, wurden für die Anwendung im Test- und Demonstrationssystem (vgl. Kapitel 2.3.6) Rollen definiert, für die eine Auswahl der wirklich notwendigen Informationseinheiten gemeinsam bestimmt wurde, die sich aus dem Anwendungsfall aus der Funktion und den (typischen) Befugnissen des Anwenders ergeben. Nachfolgendes Beispiel für den Anwendungsfall Anlagenbegehung zeigt, dass bereits mit wenigen Auswahlkriterien eine ausreichend genaue Beschreibung erreicht werden kann, wobei einige Kriterien auch automatisch festsetzbar sind. Im Beispiel: Wird eine Maßnahme für notwendig erachtet (02-13 Dringlichkeit von Maßnahmen), kann die entsprechende ZEUS-Statusinformation auch automatisch generiert werden. Abbildung 9: Relevante Merkmale aus dem ZEUS-Schlüsselsatz für den Anwendungsfall Anlagenbegehung ZEUS soll mit den im Projekt EVW genannten Erfahrungen schrittweise weiterentwickelt werden, als nächster Schritt ist geplant, einen Anwendungsleitfaden herauszugeben, um den Nutzen von ZEUS für die Anwender transparent zu machen, und Möglichkeiten für einen effektiven Praxiseinsatz für Anwender und Systementwickler aufzuzeigen. Der erste Entwurf dieses Anwendungsleitfaden ist dem Bericht als Anlage beigefügt. Abschlussbericht EVW Phase

28 2.1.3 Globales Service Protokoll Darstellung der Das Globale-Service-Protokoll (kurz GSP) ist eine auf Initiative und unter wesentlicher Beteiligung der EVW-Projektpartner entwickelte Richtlinie, die ein Austauschformat für die Übermittlung von Instandhaltungsdaten (Auftragsdaten und Berichtsinformationen) für den Bereich der erneuerbaren Energien beschreibt. Als TR 7 Rubrik D3 ist das GSP seit Januar 2014 Teil der Technischen Richtlinien der FGW. Die grundlegende Beschreibung des GSP ist kostenfrei bei der FGW zum Download ( erhältlich. Dieses Kapitel enthält daher nur eine zusammenfassende Darstellung zum GSP, Details sind in der Richtlinie zu finden. Abbildung 10: Anwendungsfelder und Vorteile des GSP Ähnliche Ansätze sind aus der Instandhaltung von technischen Anlagen bisher nicht bekannt. Beispiele für die Einführung eines einheitlichen Datenformates sind ISYBAU, welches den standardisierten Austausch von Daten zu Planung, Bau und Betrieb von abwassertechnischen Anlagen erlaubt, oder das in der Baubranche zum Einsatz kommende GAEB-Austauschformat. Beide Formate sind frei zugänglich und XML-basiert. Die genannten Beispiele bilden zwar inhaltlich keine Grundlage für die Entwicklung des GSP, wurden allerdings bzgl. ihrer Struktur als Beispiel herangezogen. Anhand eines XML-Schemas definiert das GSP die Struktur und Bezeichnungen für die Verwendung von XML-Dateien zum Austausch von Instandhaltungsdaten. In Anlehnung an das Open-Document- Format (ODF) handelt es sich bei GSP-Dateien (*.gsp) um ZIP-Files, die neben den Instandhaltungsdaten im XML-Format auch ergänzende Bilder, Tondateien etc. enthalten können. Durch die verwendeten Formate in das GSP-Plattformunabhängig und lässt sich in jede bestehende Arbeitsumgebung implementieren. Die Hauptmerkmale des GSP-Datenaustauschformates sind: Dokumentenstruktur im Open Document Format (GSP-Dokument) Ablage der Instandhaltungsdaten in einer an den Bedürfnissen der Instandhaltung im Bereich der erneuerbaren Energien orientierten, benutzerspezifisch anpassungsfähigen XML-Struktur (GSP-Datenformat) Integration der branchenüblichen Standards zur Ereignisklassierung und Beschreibung ZEUS (nach FGW-TR 7 Rubrik D2) und RDS-PP (nach VGB Anwendungsrichtlinie Teil 32 RDS-PP für Windkraftwerke) Beschreibungsmöglichkeit für Anlagenzustand und Komponentenzustand entsprechend des ZEUS Schlüssels Historisierung von Zustandsdaten an Anlagen und Komponenten im Serviceprozess Abschlussbericht EVW Phase

29 Darstellung der Das im GSP definierte Datenformat erfüllt folgende Funktionen: Austausch von Daten zu Instandhaltungsmaßnahmen zwischen den Akteuren als Voraussetzung für die Übermittlung und Zusammenstellung der IH- Dokumente und Datenbanken Zuordnung der in das GSP-Datenformat integrierten Informationseinheiten zu einzelnen IH- Maßnahmen (Aufträge) Zuordnung der in das GSP-Datenformat integrierten Informationseinheiten zu den relevanten Anlagen- und Anlagenteilen Herstellung der Vergleichbarkeit für einzelne Instandhaltungsfälle durch die Implementierung eines einheitlichen Datenformates und einer einheitlichen Zuordnungslogik, welche mit der Anwendung von RDS-PP auch funktionale Strukturen abbildet. Dokumentationsmöglichkeit der Schadbefundung, das heißt dem Weg von der Schadvermutung bis zur Fehlerbefundung Hintergrund und Zielsetzung Hintergrund für die Erarbeitung des GSP war die in Kapitel 1.1 beschriebene Herausforderung Instandhaltungsdaten in auswertbarer Form zu erfassen und zwischen den verschiedenen beteiligten Parteien auszutauschen. Da die so ermöglichte Datenqualität wichtige Grundlage für das EVW-Projekt ist, hat die Entwicklung und Verbreitung eines einheitlichen Informationsprotokolls, welches die leichte, elektronische Austauschbarkeit von Informationen zwischen allen an der Instandhaltung beteiligten Parteien (Inspektoren, Servicedienstleister, Betriebsführer) für die EVW-Projektpartner eine hohe Priorität. Wie eine vom Fraunhofer IWES für den AK GSP durchgeführte Umfrage zeigt, steht den an Betriebund Instandhaltung von WEA beteiligten Unternehmen nur rund ein Drittel der als notwendig erachteten Daten in digitaler Form zur Verfügung. Eine zum Austausch ebenfalls notwendige Kompatibilität der Daten ist in dieser Untersuchung noch nicht berücksichtigt. Abbildung 11: einer Umfrage des Arbeitskreis GSP der FGW e.v. zur Notwendigkeit und Verfügbarkeit von Daten in der Betriebsphase von WEA. Abschlussbericht EVW Phase

30 Darstellung der Anlass für Entwicklung des GSP-Datenaustauschformates war die Vision einer Reihe von Nutzeffekten, welche der Förderung der Zuverlässigkeitsbasierten Instandhaltung im Rahmen der bestehenden Marktstruktur im Bereich der Windenergie in Deutschland dienen können: Mit der Festlegung eines Datenaustauschformates werden unterschiedliche Akteure (Betriebsführer, Gutachter, Servicedienstleister, Hersteller usw.) mit unterschiedlichen IT-Systemen in die Lage versetzt, Daten elektronisch auszutauschen. Durch Vereinheitlichung erhalten die unterschiedlichsten Konstellationen von Akteuren die Möglichkeit, künftig ein branchengeeignetes, klar definiertes Datenformat für den Austausch von Instandhaltungsdaten vertraglich zu vereinbaren. Der Datenaustausch ermöglicht die Anlage von strukturierten Datenbanken, welche als Grundlage für eine analytische Systemanalyse und Instandhaltungsoptimierung benötigt werden. Die zur klassifizierten Beschreibung von Instandhaltungstätigkeiten dienenden Richtlinien ZEUS und RDS-PP können in das Format integriert werden, wodurch eine belastbare oder vergleichbare Zuverlässigkeitsauswertung überhaupt erst möglich wird. Durch die Spezifikation einer Datenstruktur wird mittelbar ein klarer Hinweis gegeben, welche Instandhaltungsdaten als Grundlage für eine Instandhaltungsoptimierung überhaupt systematisch zu erfassen wären. Unmittelbar wird durch die Anwendung einer umfassenden Datenstruktur der Anreiz für eine höhere Datenqualität und die Schaffung dafür geeigneter IT-Werkzeuge gefördert. Eine anbieter- bzw. typenübergreifende Datenanalyse (s. Abschnitt 2.2) oder Systemanalyse (s. Anschnitt 2.3) wird wesentlich einfacher umsetzbar, da sie auf funktionale Aspekte und ein anerkanntes Strukturierungssystem für WEA (RDS-PP ) gestützt werden kann. Zudem eröffnet die Anwendung von ZEUS und RDS-PP Chancen für eine optimalere Assistenz der Anwender durch die IT-Systeme, da die Benutzereingaben und Informationen für die Anwendungsfälle automatisiert individuell angepasst werden könnten (s. Abschnitt 2.1.4). Der Aufbau von Instandhaltungsdatenbanken (s. Abschnitt 2.2) wird bei einem einheitlichen Quelldatenformat wesentlich erleichtert, selbst wenn nicht alle Datenlieferanten dieselbe Erfassungstiefe und unterschiedliche IT-Systeme (z.b. Software) verwenden Instandhaltungsprozess und Anforderungsdefinition Die Anforderungen an das GSP leiten sich zum einen aus den in Kapitel beschriebenen Zielen sowie im Wesentlichen aus den Erfordernissen des Instandhaltungsprozesses ab. Grundlage hierfür ist ein im AK GSP erarbeiteter Musterprozess zur Auslösung und Durchführung von Instandhaltungsaufträgen mit einem Schwerpunkt auf die für die Erfassung von Instandhaltungsdaten und den Datenaustausch zwischen den verschiedenen Parteien. Abschlussbericht EVW Phase

31 Darstellung der Auftraggeber (Betreiber/Betriebsführer) Auftragnehmer (Hersteller/Serviceunternehmen) Serviceleiter Servicetechniker Im Falle eines Standard-Wartungsvertrags Im Falle eines Full Service Wartungsvertrags Stammdaten Zustand nach ZEUS Block 1 und 2 Historie Auftrag erstellen Medien Messpunkte Historie Stammdaten Messpunkte Auftrag erstellen Zustand nach ZEUS Block 1 und 2 Medien GSP Messmittel Arbeitsmittel Kontrolle der Voraussetzungen (auch Angebotserstellung) Qualifikationen / Unterweisungen GSP Status Information Material Bearbeiter (ID) Ressourcenplanung Wetterinformationen GSP Witterungsbedingungen Umfeldinformationen Kontrolle und Ergänung Zustand nach ZEUS Block 1 und 2 Stammdaten Einsatzplanung Auftragsdaten anpassen GSP Auftragsposition bearbeiten betroffene Elemente Arbeitspositionen Notwendigkeit der Maßnahme prüfen Betreiber informieren Getauschte / Geänderte Elemente Messmittel Zeiten Messwerte Datenerfassung zur Auftragsposition (Protokollposition) Hilfsstoffe / Verbrauchsmaterial Arbeitsmittel Zustand nach ZEUS Block 2 Bemerkung Bearbeiter (ID) GSP Instandhaltungsmaßnahme abschließen Zustand nach ZEUS Block 1 Plausibilitätsprüfung und Ergänzung GSP Auftragsabschluss Protokoll prüfen Abschluss Auftrag Abbildung 12: Musterprozess, welcher in die Entwicklung des GSP einfloss (gem. TR7 Rubrik D3 Abschnitt 3.8) Auf Basis des Musterprozesses wurde weiterhin ein IT-Prozess (siehe Abbildung 13: IT-Prozessablauf (gem. TR7 Rubrik D3 Rev. 0 Abschnitt 3.9) skizziert, welcher insbesondere für die Strukturierung und Historisierung der Informationen über den Verlauf eines IH-Vorganges im GSP herangezogen wurde. Abschlussbericht EVW Phase

32 Darstellung der Abbildung 13: IT-Prozessablauf (gem. TR7 Rubrik D3 Rev. 0 Abschnitt 3.9) Im Ergebnis der Diskussion um den Musterprozess und die IT-Anforderungen wurde festgelegt, dass die folgenden Anwendungsfälle abzudecken sind, was eine Erweiterung oder Anwendung in anderen Bereichen nicht ausschließt. Anwendungsfall (nach DIN EN 13306) Instandsetzung (Reparatur) Konformitätsprüfung (Inspektion) Zustandsüberwachung Nachweisprüfung (WPK) Routine-Instandhaltung (Wartung) Revision Fehlerdiagnose Verbesserung Änderung Grundüberholung Tabelle 1: Anwendungsfälle für das Globale Serviceprotokoll Weiterhin ist das GSP so zu gestalten, dass: Eine Übertragbarkeit auf die Anforderungen der o.g. Anwendungsfälle denkbar ist Eine Erweiterbarkeit um eigene Informationseinheiten gegeben ist (benutzerspezifische Inhalte) Die Integration von Fotos, Dokumenten mit Berichten, Arbeitsanweisungen, Auszügen aus der Anlagendokumentation in die auszutauschenden Dokumente möglich sein soll. Eine weitere Anforderung und die Nutzbarkeit des GSP im Offlinebetrieb, daher ohne Zugriff auf eine zentrale Server-Infrastruktur. Das GSP muss daher den kompakten Austausch aller relevanten IH-Daten Abschlussbericht EVW Phase

33 Darstellung der und für die Bearbeitung eines IH-Vorganges relevanten Informationen erlauben. Als Zielsetzung wurde daher die Zusammenfassung aller relevanten Informationen in einem GSP-Dokument festgelegt. Die Fertigstellung des Richtlinienentwurfes wurde außerdem von folgenden parallel laufenden Aktivitäten befruchtet, wobei ein Informations- und Meinungsaustausch außerhalb und innerhalb der Arbeit des AK GSP und im FAIH erfolgte Das GSP-Datenaustauschformat GSP-Dokument (*.gsp) basieren auf ZIP-Archiven und können Daten zum mehreren Instandhaltungsaufträgen bzw. Instandhaltungsberichten umfassen. Neben den eigentlichen Instandhaltungsdaten können auch Anhänge in diesem ZIP-Archiv abgelegt und in den Instandhaltungsdaten referenziert werden. Darüber hinaus enthält ein GSP-Dokument auch ein übersichtsgebendes Manifest. Die Festlegung der Grundstruktur des GSP erfolgt in folgenden Dateien: XML-Schemadefinition für das Manifest der *.gsp Datei (GSP-Dokumentenformat) XML-Schemadefinition für den Aufbau der mit XML strukturierten Daten (GSP-Datenformat) GSP-Dokument Manifest Beschreibt den Aufbau der *.gsp-datei sowie eine Liste aller Attachments Enthalten Verweise auf Attachments GSP Daten im XML- Attachments Format XML-Datei 0 GSP Daten im XML- Format Attachments XML-Datei 0... Abbildung 14: Aufbau des GSP Datenaustauschformates Als Grundlage für die Ablage der im GSP-Dokument vorgesehenen Informationen dient das XML- Datenformat, wodurch eine plattformübergreifende Lesbarkeit und sachgerechte Weiterverarbeitung der Daten sichergestellt ist. Die einheitliche Struktur der XML-Dateien des GSP wird durch ein XML- Schema sichergestellt. Dieses definiert neben der Struktur auch die Benennung einzelner Datenfelder und enthält Vorgaben zu den Inhalten der einzelnen Felder um ein Verständnis zwischen verschiedenen Parteien sicherzustellen. Mit demselben Ziel wurden in den Richtlinienentwurf Empfehlungen bzw. Vorgaben für Kategorien (Enumerationen) eingefügt (vgl. Abschnitt 6 der Richtlinie). Gleichfalls erfolgte, wo dies für notwendig erkannt wurde, eine Anpassung der Begrifflichkeiten und Kategorien auf bestehende Normen: Zu nennen sind hier neben der TR7 Rubrik D1 insbesondere die DIN EN (Begriffe der Instandhaltung) und die DIN EN (Dokumente für die Instandhaltung), aber auch das Common Information Model (CIM) der Distributed Management Task Force (DMTF). Abschlussbericht EVW Phase

34 Darstellung der Abbildung 15: Hauptklassen im XML-Schema des GSP Das GSP umfasst generell: verpflichtende Informationseinheiten, die von allen Teilnehmern angewendet werden müssen zulässige (optionale) Informationseinheiten, welche entsprechend des jeweiligen Anwendungsfalles ergänzt werden (können) eine zulässige Struktur für benutzerspezifische Erweiterungen, welche auf der Basis gegenseitiger Vereinbarungen zwischen den Anwendern festgelegt werden können Das XML-Schema wurde in Anlage A der GSP Richtlinie FGW TR7 Rubrik D3 vollständig dokumentiert Bisherige Erfahrungen und Ausblick Mit Fertigstellung des Richtlinienentwurfes liegt seit Anfang 2014 ein Datenaustauschformat vor, welches geeignet ist eine systematische IH-Datenerfassung und Übertragung auf vergleichbaren Auswertungsebenen zu gewährleisten. Daten, welche den Anforderungen des GSP-Standards genügen, erlauben durch die Übertragung von ZEUS und vor allem RDS-PP Daten eine Analyse auf funktional vergleichbaren Ebenen der Systemstruktur (s.a. Abschnitt 2.1.4) mit vergleichbaren Kategorien der Zustandsbeschreibung. Da die Erweiterung von IT-Systemen oder kommerzieller Software kostenintensiv ist, und eine Anpassung von Prozessen oder Verträgen bedeutet, kann eine Einführung des GSP in der Windbranche nur Schrittweise erfolgen. Implementierungschancen werden vor allem gesehen, wenn: die Vertragspartner bei Serviceverträgen wechseln oder neue Verträge abgeschlossen werden, bestehende IT-Systeme neu aufgebaut oder umgebaut werden, Softwareupdates eine kostengünstige oder kostenlose GSP-Schnittstelle enthalten. Bereits während der Erstellung des Richtlinienentwurfes zeigte auch das Interesse von Softwarefirmen an der GSP-Richtlinie. Beispielsweise betonte die PC-Soft GmbH (Anbieter der Instandhaltungsplattform zedas asset management) während den 23. Windenergietagen im November 2014 die Bedeutung der des EVW-Projektes und führte das GSP als zu berücksichtigende Richtlinie auf. Eine erste Umsetzung ist durch die Firma RECONSERV GmbH & Co KG im Softwarepaket REGAS (siehe auch Kapitel 2.4.5) erfolgt, welches auf der WindEnergy Hamburg 2014 vorgestellt wurde. Von weiteren Unternehmen ist die Prüfung der GSP-Implementierung bzw. die laufende Umsetzung (EVW- Projektpartner ENERTRAG Windstrom) bekannt. Abschlussbericht EVW Phase

35 Darstellung der Im Rahmen der Implementierung sind sowohl im EVW-Projekt als auch bei externen Firmen erste kleinere Fehler im GSP-Protokoll aufgefallen und Ideen zu Erweiterung entstanden. Vor diesem Hintergrund soll der AK GSP seine Arbeit Mitte 2015 wieder aufnehmen und den Bedarf einer Weiterentwicklung prüfen. Der Input von ersten Anwendern ist hierzu zwingend erforderlich. Darüber hinaus wird es Aufgabe des AK GSP sein, den Bekanntheitsgrad des GSP zu erhöhen. Die Bandbreite reicht hier von Veröffentlichungen in Fachzeitschriften, bis hin zur Teilnahme an Messen und Ausstellungen, aber auch internationaler Normen- und Gremienarbeit (siehe auch Kapitel ). Zur Debatte steht ebenfalls die Erläuterung der praktischen Anwendungsmöglichkeiten in Form eines Anwendungsleitfadens. Weiterer Forschungs- und Entwicklungsbedarf zum Thema GSP wird von den EVW-Projektpartnern hinsichtlich folgender Punkte gesehen: Ausweitung auf andere Anwendungsfälle, insbesondere für die komplexen Prozesse im Bereich der Instandhaltung von Offshore-WEA (z.b. Zollabwicklung). Eignung für andere Technologien der erneuerbaren Energien, da das GSP bisher stark auf die Bedürfnisse der Windbranche ausgerichtet ist. Integration in Standardsoftware für das Instandhaltungsmanagement bzw. Schaffung entsprechender Softwarelösungen Reference Designation System for Power Plants (RDS-PP ) Für die Kennzeichnung von technischen Anlagen und Betriebsmitteln existiert ein umfassendes internationales Normen- und Regelwerk. Üblicherweise werden im Rahmen der Anlagenkennzeichnung um Standorte, Werke, Systeme, Funktionen und Betriebsmittel oder Anschlüsse gekennzeichnet, um in der Anlagendokumentation eine durchgehende und nach einheitlichen Kriterien geschlüsselte Referenz zu erhalten. Kennzeichen für Teilsystem Betriebsmittelkennzeichen im Schaltbild Einbauort und Betriebsmittelkennzeichen Abbildung 16: Anlagenkennzeichnung nach DIN EN für ein Energieversorgungssystem Abschlussbericht EVW Phase

36 Darstellung der Das Reference Designation System for Power Plants, kurz RDS-PP als Weiterentwicklung des KKS (Kraftwerks-Kennzeichen-System), ist ein als ISO/TS zur Normierung vorgelegtes System zur Anlagenkennzeichnung, d.h. der Kennzeichnung von technischen Objekten und deren Dokumentation in Kraftwerken. Es nutzt die für Kennzeichnungssysteme vorgesehenen Strukturierungsprinzipien und Regeln zur Referenzkennzeichnung aus der internationalen Normenwelt, z.b. der IEC / EN / DIN EN RDS-PP erhebt den Anspruch für alle Phasen aller Kraftwerkstypen anwendbar zu sein und bietet im Wesentlichen weitere, branchenspezifische Tabellen mit Buchstabencodes, welche die Tabellen der IEC / EN / DIN EN ergänzen. Bisher wurde RDS-PP selbst weder von der DIN noch von der ISO als Norm bzw. Standard herausgebracht und trägt daher den DIN-Entwurfs-Status "Vornorm" bzw. den ISO-Entwurfs-Status "Technical Sheet" ISO/TS. Für die Anwendung im Bereich der Windenergie hat der VBG 2014 die Richtlinie VGB-S823-T32 RDS- PP Anwendungsrichtlinie Teil 32: Windenergie herausgegeben. Im Zuge der Veröffentlichung hat der VGB auch die Lizensierung an die zu erwartende wirtschaftliche Verwertung angepasst und unterscheidet zwischen Lizenzen für Anwender (Eigene Anlagen) Dienstleister (Anlagenkennzeichnung für Dritte) Entwickler für Software und Datenbanken Die Ende 2014 erschienene Richtlinie wurde vom VGB-Arbeitskreis Anlagenkennzeichnung und Dokumentation erarbeitet, in dem Betreiber und Instandhalter sowie Planer und Hersteller von Kraftwerken vertreten sind. Die Arbeit des Arbeitskreises bei der Erstellung beinhaltete im Wesentlichen die Vergabe der Kennbuchstaben, Grundfunktionen und Produktklassen für Windenergieanlagen. Hierzu gab es eine informelle und fachliche Zusammenarbeit des EVW-Projektteams mit dem VGB (s. Kapitel ), der Standard selbst ist jedoch kein EVW-Projektergebnis. Zur Erfüllung der Aufgaben, welche im EVW-Projekt geleistet werden, kommt ihm als nationale Empfehlung zur Umsetzung der Anlagenkennzeichnung nach internationalen Normen eine wichtige Rolle zu. Die Anlagenkennzeichnung nach der RDS-PP Richtlinie wurde auch im globalen Serviceprotokoll berücksichtigt. Im GSP (s. Kapitel ) wurde die Anwendung einer auf RDS-PP referenzierbaren Systemstruktur implementiert. Die Referenzierung bei der Angabe der zuweisbaren Elemente im GSP berücksichtigt den Umstand, dass jedes in der Anlagenstruktur mit einem Betriebsmittelkennzeichen versehene Objekt aus mehreren tauschbaren Einheiten (Teilkomponenten bzw. Teilsystemen) bestehen kann, welche das Objekt realisieren. Abschlussbericht EVW Phase

37 Darstellung der Abbildung 17: Auswertung von Instandhaltungsdaten nach RDS-PP Betriebsmittelkennzeichen Zur Herstellung der Kompatibilität unterschiedlicher IT-Systeme verlangt die GSP-Richtlinie deshalb die Anwendung des Referenzkennzeichensatzes RDS-PP (Referenzierung auf Betriebsmittelkennzeichen). Dies eröffnet perspektivisch nicht nur die Möglichkeit, mit dem GSP übertragene Instandhaltungsdaten nach funktionalen Gesichtspunkten, d.h. für Teilsysteme vergleichbarer Funktion, aufzubereiten (s. auch Kapitel 2.1.3), sondern auch die Darstellung und Eingabe der Instandhaltungsdaten sowie der Zusatz-informationen in den IT-Systemen entsprechend der Art und Funktion des instandzuhaltenden Betriebsmittels zu gestalten. Am Beispiel: Die Vergabe der ZEUS-Schlüssel für die Abweichung vom Soll-Zustand für die unterschiedlichen Betriebsmittel wäre anhand des RDS-PP Kennzeichens steuerbar. Nutzeffekt: Die Auswahl der in Frage kommenden Kriterien kann auf ein überschaubareres Maß begrenzt werden. Geht man noch weiter, und führt eine durchgängige Kennzeichnung auch für Anlagendokumentation ein, könnten dem Techniker auf der Anlage für jedes Betriebsmittel automatisch die Informationen mitgegeben werden, welche für die Instandhaltung des Betriebsmittels relevant sind. Anhand des Kennzeichens könnte eine IH-Software automatisch Verweise oder Dokumente für die Instandhaltung zusammenstellen, die im GSP übertragen werden können. Abschlussbericht EVW Phase

38 Darstellung der 2.2 Aufbau und Betrieb des WInD-Pool Ziel des WInD-Pool ist es, die Windenergiebranche auf Basis einer breiten statistischen Datenbasis bei ihren unternehmerischen Entscheidungen mit Informationen zu unterstützen und so perspektivisch die Stromgestehungskosten zu senken. Die Abkürzung WInD-Pool steht für Windenergie-Informations-Daten-Pool. Es handelt sich um eine gemeinsame Erfahrungs- und Wissensdatenbank der Windbranche die im Rahmen des EVW-Projektes konzipiert und aufgebaut wurde und auch zukünftig betrieben und weiterentwickelt werden soll. Im WInD-Pool werden unternehmensübergreifend Betriebs- und Instandhaltungsdaten gesammelt und ausgewertet. Auf Basis des WInD-Pool lässt sich zum einem ein Benchmark des Anlagenportfolios für die beteiligten Unternehmen erstellen, zum anderen aber auch die Zuverlässigkeit von WEA, Systemen und einzelnen Komponenten untersuchen. Die durch das EVW-Projekt erarbeitete und folgend beschriebene Datenbasis konzentriert sich auf an Land installierte WEA. Daten zu Offshore-WEA werden im Projekt Offshore~WMEP (FKZ: A) erhoben, welches durch das Fraunhofer IWES durchgeführt wird. Durch die enge Abstimmung zwischen beiden Projekten sind die Datenbasen weitgehend kompatibel gestaltet und ließen sich bei Zustimmung aller beteiligten Parteien zukünftig zusammenführen. Der WInD-Pool adressiert die Tatsache, dass es sich bei der Windbranche um einen heterogenen Wirtschaftszweig mit einer Vielzahl an hauptsächlich kleinen und mittelständischen Unternehmen handelt sowie diverse Anlagenkonzepte und typen existieren. Statistisch belastbare unternehmensinterne Auswertungen, beispielsweise bei einem Betreiber von WEA, scheitern so häufig an einem breiten Anlagenportfolio, welches keinen sinnvollen Vergleich zulässt. Werden die unterschiedlichen in Deutschland existierenden Standortbedingungen bei den Auswertungen berücksichtigt, verringert sich der jeweilige Stichprobenumfang weiter. Auf Basis des WInD-Pool lässt sich die Performance des Portfolios eines einzelnen Unternehmens gegenüber der Grundgesamtheit der WEA aller teilnehmenden Unternehmen einordnen. Unternehmensspezifische Schwachstellen bei Betrieb und Instandhaltung von WEA können so aufgedeckt werden. Durch ein regelmäßiges Reporting kann die Wirksamkeit ergriffener Maßnahmen schnell geprüft werden. Aussagen über die reale Zuverlässigkeit von Windenergieanlagen, insbesondere über das Zuverlässigkeitsverhalten einzelner Komponenten und Systeme, können unter Verwendung von Felddaten nur auf Basis umfangreicher Betriebserfahrung getroffen werden, was in der Windbranche meist vielen Betriebsjahren entspricht. Wird der Stichprobenumfang einer Auswertung erhöht, was eine Betrachtung zusätzlicher WEA bedeutet, kann der Test- bzw. Betrachtungszeitraum bei gleichbleibender Aussagesicherheit verkürzt werden. Die unternehmensübergreifende Auswertung von Instandhaltungsinformationen im WInD-Pool setzt an dieser Stelle an und ermöglicht es belastbare Zuverlässigkeitsdaten schneller zu erzeugen bzw. die Aussagesicherheit der Analysen zu erhöhen. Unter Verwendung dieser Informationen können moderne präventive Instandhaltungsstrategien den Aufwand für die Instandhaltung verringern, ohne dass dabei die Verfügbarkeit der Systeme negativ beeinträchtigt wird. Abschlussbericht EVW Phase

39 Darstellung der O&M-Daten Auswertungen Benchmarks Beratungspartner Abbildung 18: Grundprinzip des WInD-Pool Das Grundprinzip des WInD-Pool ist denkbar einfach. Die sogenannten Datenlieferanten (z.b. Betreiber) spielen ihre Betriebs- und Instandhaltungsinformationen in einem einheitlichen Format in den durch das Fraunhofer IWES als Datentreuhänder betriebenen WInD-Pool ein. Nach Prüfung und Validierung der Daten werden - unter Sicherstellung der Vertraulichkeit und Anonymität - standardisierte Benchmarks und Auswertungen erstellt und schließlich dem Datenlieferanten wieder zur Verfügung gestellt. Werden Auffälligkeiten oder Optimierungspotentiale erkennbar, können hierzu - in Zusammenarbeit mit Fraunhofer IWES und IZP Dresden - Detailuntersuchungen durchgeführt und Lösungen entwickelt werden. Der WInD-Pool gewährleistet durch eine einheitliche Kooperationsvereinbarung die rechtliche Absicherung aller beteiligten Parteien und schafft so die Basis einer guten und vertrauensvollen Zusammenarbeit. Erste Kooperationspartner sind die EVW-Projektpartner. Der Beitritt weiterer Unternehmen ist jederzeit möglich und für den Erfolg der Initiative unabdingbar. In den folgenden Unterkapiteln wird der WInD-Pool detailliert beschrieben. Die wichtigsten Informationen sind auch online unter verfügbar Datenumfang und verwendete Standards Sollen Daten erfasst, gespeichert und ausgewertet werden, geschieht dies immer unter dem Grundsatz: So wenig wie möglich aber so viel wie nötig. Diese Aussage steht vor dem Hintergrund, dass der Aufwand für die Erfassung, den Transfer und die Speicherung von Daten auch bei der Verwendung digitaler Systeme nicht zu vernachlässigen ist. Insbesondere bei zusätzlichen Daten, die evtl. auch manuell erfasst werden müssen, muss ein zusätzlicher Nutzen klar erkennbar sein. Bei einer unternehmensübergreifenden Initiative wie dem WInD-Pool kommt hinzu, dass auszuwertenden Daten von allen oder zumindest von einem Großteil der beteiligten Unternehmen vorliegen sollten. Da alle Informationen zu Auswertungszwecken in einem einheitlichen Format vorliegen müssen, ist die Form in der die Daten bei den beteiligten Unternehmen vorliegen ebenfalls von großer Bedeutung. Für den WInD-Pool wurde in Zusammenarbeit aller Projektpartner und in Abstimmung mit dem Projektbeirat ein Minimaldatenkatalog (Tabelle 2) für den erfolgreichen Betrieb definiert und in Anlage B zur Kooperationsvereinbarung (siehe auch 2.2.5) dokumentiert. Daten die über den Minimaldatenkatalog hinaus bereitgestellt werden, lassen sich ebenfalls in den WInD-Pool integrieren und können zu gegebenen Zeitpunkt ohne einen erneuten Datentransfer für weitere Analysen herangezogen werden. Abschlussbericht EVW Phase

40 Darstellung der Stammdaten Betriebsdaten Ereignisdaten Kostendaten (optional) Anlagenidentifikation Turbinenleistung Eindeutige Ereignis-Ident. Gesamte O&M-Kosten Anlagentyp Windgeschwindigkeit Ereigniseintritt Gesamte Kosten je Ereignis Inbetriebnahmedatum Windrichtung Ende der Maßnahme Beginn der Datenerfassung Längengrad Breitengrad Betroffene Komponenten (idealerweise nach RDS-PP ) Ereignisart (idealerweise nach ZEUS) Tabelle 2: Zusammenfassung des Minimaldatenkatalogs des WInD-Pool entsprechend Anlage B der Kooperationsvereinbarung zum WInD-Pool Die Definition des Minimaldatenkatalogs folgt dabei folgenden Leitfragen: Welche Informationen werden zur Definition der zu untersuchenden Grundgesamtheit (z.b. bestimmte WEA-Typen oder Standortkategorien) benötigt? Welche Informationen sind für einen Benchmark des Anlagenbetriebs erforderlich? Welche Informationen werden als Lebensdauermerkmale für die Untersuchung der Anlagenzuverlässigkeit benötigt? Wie müssen Ausfälle von Systemen oder einzelnen Komponenten beschrieben werden um Zuverlässigkeitskennwerte zu bilden? Welche Kosteninformationen müssen erfasst werden um Instandhaltungsstrategien zu optimieren oder Lebenszykluskosten berechnen zu können? Welche Informationen sind bei möglichst vielen Betreibern von Windenergieanlagen vorhanden und würden von diesen auch zur Verfügung gestellt werden? In welcher Form bzw. unter Verwendung welcher Standards und Richtlinien sind die benötigten Informationen zu erfassen und bereitzustellen? Eine Untersuchung dieser Leitfragen zeigt, dass sich die benötigten Daten grundlegend in Stammdaten, Betriebsdaten, Ereignisdaten und Kostendaten untergliedern lassen. Abschlussbericht EVW Phase

41 Stammdaten Darstellung der Bei Stammdaten handelt es sich um Daten, welche die grundlegenden, in der Regel unveränderlichen Eigenschaften der zu betrachtenden Objekte beschreiben. Untersuchungsobjekte des WInD-Pool sind WEA. Bei der Aufnahme einer WEA in den WInD-Pool sind mindestens eine eindeutige Anlagenidentifikation, eine Bezeichnung des Anlagentyps, das Inbetriebnahmedatum und der Beginn der Datenerfassung sowie Standortinformation in Form von Längen- und Breitengrad zur Verfügung zu stellen. Alle weiteren Informationen werden im WInD-Pool dem so definierten Objekt zugeordnet, siehe auch Abschnitt Auf Basis der bereitgestellten minimalen Stammdaten lassen sich im WInD-Pool weitere Informationen ohne zusätzlichen Aufwand für die beteiligten Datenlieferanten ergänzen. Zu nennen sind an dieser Stelle beispielsweise Daten zum Anlagentyp wie Leistung oder Rotordurchmesser, die auf Basis der Bezeichnung des Anlagentyps verknüpft werden können aber auch Informationen (z.b. Höhe über dem Meeresspiegel, DIBt-Windzone etc.) die aus der Verknüpfung der Standortkoordinaten mit ergänzendem Kartenmaterial hervorgehen. Aufgrund der geringen Datenpunkte und die einmalige Bereitstellung und Verarbeitung der Datensätze werden an die Form der Stammdaten keine besonderen Anforderungen gestellt. Die Bezeichnung des Anlagentyps sollte möglichst den Bezeichnungen des Anlagenherstellers entsprechen und die Übermittlung des Standorts als Dezimalkoordinaten erfolgen Betriebsdaten Unter Betriebsdaten oder Betriebsparametern sind alle Daten zu verstehen, welche die Betriebsbedingungen und den Betrieb der WEA beschreiben. Es handelt sich beispielsweise um Witterungsbedingungen, Spannungen, Ströme, Temperaturen etc. In der Praxis werden entsprechende Daten durch die SCADA-Systeme (Supervisory Control and Data Acquisition) der WEA aufgezeichnet und dem Anwender zur Verfügung gestellt. Um den Datenumfang zu reduzieren sind in der Windbranche Mittelwerte über einen Zeitraum von 5, 10 oder 15 Minuten üblich. Die Betriebsdaten haben in Bezug auf den Datenumfang somit den größten Anteil an der Datenbasis. Minimaldaten für den WInD-Pool sind Windgeschwindigkeit, Windrichtung und Anlagenleistung. Bei der Windgeschwindigkeit [m/s] handelt es sich um die von der WEA auf Nabenhöhe gemessene Windgeschwindigkeit. Die Windrichtung [ ] ist als Winkel zwischen 0 und 360 anzugeben, wobei 0 und 360 einem aus Norden kommenden Wind entsprechen. Ist dieser Wert nicht bekannt, kann im Zweifel auch auf die Ausrichtung der Rotornabe zurückgegriffen werden. Zu beachten ist, dass WEA bei einem Stillstand nicht nachgeführt werden und die Gondelposition in diesem Fall nicht der Windrichtung entspricht. Die Anlagenleistung ist als Wirkleistung [kw] der WEA anzugeben. Zur Prüfung der Betriebsdaten werden neben den Mittelwerten für die jeweilige Periode auch der Minimal- und Maximalwert sowie die Standardabweichung erfasst. Die Bezeichnung der Betriebsdaten erfolgt möglichst entsprechend der IEC-Richtlinie (Kommunikation für die Überwachung und Steuerung von Windkraftwerken). Bei einer anderweitigen eindeutigen Bezeichnung kann beim Einspielen der Daten auch ein Mapping erfolgen. (siehe Kapitel 2.2.7) Ereignisdaten Unter Ereignisdaten sind in Bezug auf den WInD-Pool alle Informationen zu verstehen, welche die Änderung der Funktionsfähigkeit einer WEA oder eines Subsystems sowie die hieraus resultierenden Maßnahmen beschreiben. Beispiel für ein entsprechendes Ereignis ist der Ausfall der Windgeschwindigkeitsmessung und die damit verbundene Abschaltung der WEA. Alle Ereignisinformationen werden im WInD-Pool einheitlich abgelegt und sollten durch die beteiligten Datenlieferanten nach Möglichkeit ebenfalls einheitlich erfasst werden. Zur Beschreibung Anlagenbzw. Komponentenzustands wird der Zustands-Ereignis-Ursachen-Schlüssel (ZEUS FGW Richtlinie Abschlussbericht EVW Phase

42 Darstellung der TR7 D2 Rev. 1) herangezogen, siehe auch Kapitel Zur Bezeichnung von Komponenten bzw. Systemen einer WEA wird das Reference Designation System for Power Plants (RDS-PP, VGB-S EN-DE-0) des VGB verwendet. Werden beim datenbereitstellenden Unternehmen bereits interne Kategorien bzw. Kodierungssysteme anstelle von ZEUS und RDS-PP verwendet, kann die Konvertierung eventuell über eine entsprechend zu erstellende Zuordnungstabelle erfolgen. Daten je Ereignis Grundlegende Daten zur Beschreibung und Zuordnung eines Ereignisses. Information Event_ID WFID WTID Start_of_Event End_of_Measure Functional_State_WT [ZEUS_01_02] Type_of_Event [ZEUS_01_04] Beschreibung Eindeutige Bezeichnung des Ereignisses, wie sie auch beim bereitstellenden Unternehmen genutzt wird. Stellt sicher, dass Ereignisse nicht mehrfach aufgenommen werden und eine klare Zuordnung in der späteren Kommunikation möglich ist. Eindeutige Bezeichnung des entsprechenden Windparks, wie sie auch beim bereitstellenden Unternehmen genutzt wird. Eindeutige Bezeichnung der entsprechenden Windenergieanlage, wie sie auch beim bereitstellenden Unternehmen genutzt wird. Datums- und Zeitangabe zum Beginn des Ereignisses, z.b. Zeitstempel eines Fehlereintritts. Datums- und Zeitangabe zum Abschluss der eingeleiteten Maßnahme. z.b. Zeitstempel der Fehlerbehebung, nach der die WEA wieder funktionsfähig ist. Funktionszustand der Windenergieanlage nach Ereigniseintritt. Die Kategorisierung erfolgt nach ZEUS Block Es ist mindestens zwischen Funktionsfähiger Zustand und Anlagenbedingter Störung zu differenzieren. Art des Ereignisses, welches eine Änderung des Anlagenzustandes ausgelöst hat. Die Kategorisierung erfolgt nach ZEUS Block Es ist mindestens zwischen Ereignis mit Komponentenbezug, Ereignis mit organisatorischem Eingriff und Sonstiges Ereignis zu differenzieren. Abschlussbericht EVW Phase

43 Daten je Komponente Darstellung der Bei einem Ereignis mit Komponentenbezug erfolgt eine Nennung der Komponente sowie der Fehlerursache und der entsprechenden Instandhaltungsmaßnahme. Sind bei einem Ereignis mehrere Komponenten betroffen, werden in der vereinfachten CSV-Vorlage die Daten zum Ereignis für jede Komponenten identisch mitgeführt. Information Component [RDS-PP] Failure_Cause [ZEUS_02_05] Maintenance_Type [ZEUS_02_08] Maintenance_Measure [ZEUS_02_09] Beschreibung Eindeutige Bezeichnung der betroffenen Komponente bzw. ihrer Funktion. Idealerweise findet RDS-PP (VGB-S EN-DE-0) Anwendung. Fehlerursache. Die Kategorisierung erfolgt idealerweise nach ZEUS Block Es ist mindestens zwischen Ausfallursache innerhalb Energieanlage und Ausfallursache außerhalb Energieanlage zu differenzieren. Art der Instandhaltung. Die Kategorisierung erfolgt idealerweise nach ZEUS Block Es ist mindestens zwischen Korrektive Instandhaltung und Präventive Instandhaltung zu differenzieren. Instandhaltungstätigkeit. Die Kategorisierung erfolgt idealerweise nach ZEUS Block Es ist mindestens zwischen Tausch der Komponente und Sonstigen Instandsetzungsmaßnahmen zu differenzieren. Zusätzliche Informationen Das Erfassen und Auswerten zusätzlicher Daten ist für viele Anwendungsfälle sinnvoll, wird aber für eine Teilnahme am WInD-Pool nicht vorausgesetzt. ZEUS bietet die Möglichkeit, entsprechende Informationen zu kategorisieren. Unter anderem wird die Erfassung folgender zusätzlicher Informationen als sinnvoll erachtet. Entsprechende Informationen können ebenfalls in den WInD-Pool eingespielt werden. Funktionszustand Element (ZEUS 02-01) Erkennungsgelegenheit (ZEUS 02-02) Erkennungssymptom (ZEUS 02-03) Ausfallmodus (ZEUS 02-04) Ausfallverlauf (ZEUS 02-06) Verantwortlichkeit für die Maßnahme (ZEUS 02-10) Abweichung vom Sollzustand (ZEUS 02-12) Neu eingebaute Komponenten (Hersteller, Typ, Seriennummer) Verwendetes Material (Hersteller, Typ, Menge) Eine umfassende Auflistung weiterer Instandhaltungsinformationen kann der Dokumentation des GSP (FGW Richtlinie TR 7 D3) entnommen werden. Abschlussbericht EVW Phase

44 Optionale Kostendaten Darstellung der Da Kosteninformationen von allen beteiligten Unternehmen als besonders sensibel eingestuft werden, aber gleichzeitig unerlässlich zur Optimierung von Instandhaltungsstrategien und zur Berechnung von Lebenszykluskosten sind und auch den Benchmark bereichern, enthalten die Minimaldatenanforderung des WInD-Pool Kostendaten als optionalen Informationsblock. Sind entsprechende Daten vorhanden, werden diese entsprechend Anlage C der Kooperationsvereinbarung auch in den Auswertungen berücksichtigt. Die Kostendaten lassen sich wiederum in zwei Gruppen bzw. Detailebenen unterteilen. Für einen grundlegenden Benchmark und zur ersten Berechnung der Lebenszykluskosten sind die gesamten Betriebs- und Instandhaltungskosten je WEA und Jahr ausreichend. Eine Unterteilung in fixe IH- Vertragskosten, sonstige fixe IH-Kosten, variable IH-Kosten und sonstige Kosten ist hierbei für weitere Vergleiche wünschenswert. Um auch eine Optimierung der Instandhaltungsstrategie zu ermöglichen und Kostentreiber zu identifizieren, können darüber hinaus die Kosten pro Ereignis in den WInD-Pool aufgenommen werden. Neben den gesamten Ereigniskosten sollte auch eine weitere Untergliederung in Fahrtkosten, Kosten für Ersatzteile/Material, Lohnkosten und sonstige Ereigniskosten erfolgen Vertraulichkeitskonzept Neben der generellen Datenverfügbarkeit und der Kosten-Nutzen-Abwägung ist die Vertraulichkeit von Daten und Analyseergebnissen nach den Erfahrungen im EVW-Projekt von wesentlicher Bedeutung für teilnehmende Unternehmen. Neben Bedenken, dass aus den bereitgestellten Daten Rückschlüsse auf den Unternehmenserfolg gezogen werden können, wurden von Seiten der Betreiber auch mehrfach kartellrechtliche Bedenken geäußert, die eine Vertraulichkeit von unternehmensspezifischen Daten und n erfordern und bei übergreifenden Untersuchungen klare Regeln zur Anonymisierung erfordern. Das Vertraulichkeitskonzept des WInD-Pool wird nachfolgend zusammenfassend beschrieben, Anlage A der Kooperationsvereinbarung umfasst die komplette Definition. Abbildung 19: Vertraulichkeitskonzept des WInD-Pool entsprechend Anlage A der Kooperationsvereinbarung zum WInD- Pool Im Vertraulichkeitskonzept des WInD-Pool wird generell zwischen Daten und n unterschieden. Bei Daten handelt es sich um alle durch die Datenlieferanten/Betreiber bereitgestellten Informationen, welche entsprechend der Festlegung des Minimaldatenkatalogs (Anlage B zur Kooperationsvereinbarung) als vertraulich oder nicht vertraulich eingestuft sind. entstehen durch die Durchführung verschiedener Auswertungen und basieren auf den bereitgestellten Daten. Die aus vertraulichen und öffentlichen Daten gewonnenen werden entsprechend der Vertraulichkeit der zugrundeliegenden Daten eingeteilt. Anonymität und Abstraktion der Analysen sind entscheidend Abschlussbericht EVW Phase

45 Darstellung der für diese Einteilung bzw. die weitere Verwendung der und gestatten gleichzeitig Gestaltungsspielraum. Als können hierbei vier Möglichkeiten angesehen werden: Hochaggregierte, anonymisierte Benchmarks für die Öffentlichkeit. Auswertungen für Dritte Unternehmen/Organisationen, die selbst über keine Daten zur aktiven Teilnahme am WInD-Pool verfügen, von n des WInD-Pool jedoch profitieren können. Entsprechende Auswertungen werden auf einen aggregierten Level und nur mit Zustimmung der beteiligten Unternehmen erstellt. Bedarfsorientierte Gruppenauswertungen für Betreibergruppen. Zur Wahrung der Anonymität müssen hierzu Daten von mindesten 3 verschiedenen Berteibern in die Auswertung einfließen (z.b. vergleichende Auswertungen bzgl. Anlagenkonzept, Standorteigenschaften usw.). Analysen einzelner Windparks, welche nur dem jeweiligen Betreiber zugänglich gemacht werden. Eine Weitergabe von Daten an Dritte ist nicht gestattet. Ohne eine entsprechende Zustimmung des betroffenen Teilnehmers werden keine Daten eines Teilnehmers an einen anderen Teilnehmer weitergegeben. Die Teilnehmer bleiben dauerhaft Eigentümer ihrer Daten und haben das Recht am Ende der Kooperation die Löschung Ihrer Daten aus der Datenbank zu verlangen Reporting und Zuverlässigkeitskennwerte Entsprechend der Kooperationsvereinbarung zum WInD-Pool und der zugehörigen Anlage A werden die Daten des WInD-Pool mindestens im halbjährlichen Rhythmus ausgewertet und die den teilnehmenden Datenlieferanten zur Verfügung gestellt. Voraussetzung ist die erfolgte Bereitstellung der Betriebs- und Ereignisdaten durch die Datenlieferanten. Bei den Auswertungen ist zwischen Performance-Benchmarks, welche die Leistung des Anlagenportfolios der einzelnen Teilnehmer mit den durchschnittlichen n aller Teilnehmer im spezifischen Berichtszeitraum vergleichen und den als Kennwertebibliothek erstellten Zuverlässigkeitskennwerten, die auf Basis der zusätzlich vorliegenden Daten lediglich fortgeschrieben werden, zu unterscheiden. Abbildung 20: Automatisierte Erstellung und Verteilung anonymisierter Auswertungen auf Basis des WInD-Pool Performance-Benchmarks Abschlussbericht EVW Phase

46 Darstellung der Die Auswertung der Betriebs- und Ereignisdaten der Windenergieanlagen eines Betreibers und der regelmäßige Vergleich mit den n der Gesamtheit bietet die Möglichkeit die Performance der eigenen Windenergieanlagen und Betriebsstrategien im Vergleich zum Durchschnitt des WInD-Pool einzuordnen und bei Bedarf Maßnahmen zu ergreifen. Darüber hinaus umfasst das Reporting des WInD-Pool auch unternehmensspezifische Auswertungen auf Windpark und Anlagenebene, der Aufwand des internen Reporting der beteiligten Unternehmen kann so evtl. ebenfalls reduziert werden. Hierzu werden unter anderen folgenden Auswertungen erstellt: Vergleich des Windangebots (Windgeschwindigkeit und Windrichtung) Vergleich des Ertrags/Volllaststunden Vergleich der Leistungskennlinien Häufigkeit der Betriebszustände (z.b. zu wenig Wind, Teillast, Volllast etc.) Energetische und technische Verfügbarkeit Ereignis- und Fehlerhäufigkeit Die Auswertungen werden dabei jeweils für den kompletten Datenbestand, einzelne Gruppierungen, den jeweiligen Windpark und die jeweilige WEA durchgeführt. Die werden den beteiligten Unternehmen als PDF-Report aber auch in digitaler Form als Excel-Datei zur Verfügung gestellt. Ein auf Basis von Beispieldaten erstellter Report ist als Anhang A 4 beigefügt und enthält auch eine umfassende Beschreibung des Vorgehens bei der Datenanalyse. Kennwertebibliothek zur Anlagenzuverlässigkeit Basierend auf einem großen Datenbestand lassen sich statistische Aussagen hinsichtlich der Zuverlässigkeit von Windenergieanlagen und ihren Komponenten treffen. Der WInD-Pool schafft diese Datenbasis und ermöglicht so die Ermittlung von Zuverlässigkeitskennwerten und -funktionen. Neben grundlegenden Kennwerten wie der mittleren Fehlerrate oder der MTBF enthält die Kennwertebibliothek auch die Parameter der die Zuverlässigkeit beschreibenden Weibull-Funktionen. Die Auswertung des Zuverlässigkeitsverhaltens erfolgt auf verschiedenen Detailebenen und für unterschiedliche Gruppen. Ausgehend von der Gesamtzuverlässigkeit einer durchschnittlichen WEA als höchste Aggregationsstufe wird in der höchsten Detailstufe das Zuverlässigkeitsverhalten einer bestimmten Funktion/Komponente eines Anlagentyps unter bestimmten Standortbedingungen betrachtet. Der Detailgrad der Untersuchung hängt maßgeblich von der Qualität und dem Detailgrad der Eingangsdaten ab. Alle in der Kennwertebibliothek enthaltenen Parameter sind in Anlage A zur Kooperationsvereinbarung im Detail aufgelistet Anwendungsfelder und Nutzen Der Nutzen für einen Betreiber von Windenergieanlagen durch eine Beteiligung am WInD-Pool ergibt sich im Wesentlichen durch Bereitstellung von Auswertungen durch Fraunhofer IWES und IZP Dresden, welche erst durch eine breite Datenbasis möglich werden. Diese lassen sich grundlegend in Performance-Benchmarks und eine Bibliothek für Zuverlässigkeitskennwerte unterteilen. Anlage C zur Kooperationsvereinbarung enthält eine detaillierte Definition der standardmäßig durchgeführten Auswertungen. In vielen Unternehmen der Windbranche werden bereits heute große Anstrengungen unternommen um Zuverlässigkeitskennwerte zu generieren oder die Betriebsdaten des eigenen Anlagenportfolios auszuwerten. Mit vergleichsweise geringem Zusatzaufwand kann die Aussagekraft der über den WInD-Pool deutlich gesteigert werden. Darüber bietet der WInD-Pool die Chance die Datenauswertung zu vereinheitlichen und vergleichbare zu erhalten. Abschlussbericht EVW Phase

47 Darstellung der Weitere positive Nebeneffekte der Teilnahme am WInD-Pool sind die unternehmensinterne Optimierung der Datenerfassung und Datenhaltung sowie die Möglichkeit zum Austausch mit anderen Teilnehmern sowie Wissenschaft und Forschung. Das EVW-Projektteam verfügt durch die Umsetzung des WInD-Pool und die bisherige Datenintegration bereits über ein breites Know-how. Abbildung 21: Anwendungsfelder des WInD-Pool mit Fokus auf Betrieb- und Instandhaltung von WEA Eine Analyse (siehe Anlage A 5) des Fraunhofer IWES zu den monetären Auswirkungen bzw. dem Nutzen einer Beteiligung am WInD-Pool inkl. des konsequenten Einsatzes der Branchenstandards RDS- PP, ZEUS und GSP sowie der Anpassung von Instandhaltungsstrategien unter Nutzung von RAMS- LCC-Analysen zeigt unter den angenommenen Randbedingungen eine deutlich positives Kosten- Nutzen-Verhältnis. Der Business-Case beschränkt sich dabei auf eine Betrachtung der Effekte, die durch eine Anpassung der Instandhaltungsstrategie erzielbar sind. Weitere Anwendungsfelder des WInD-Pool wie beispielsweise der unternehmensübergreifende Benchmark, eine Optimierung von Lagerbeständen oder den Einfluss zuverlässiger Eingangsparameter in LCC-Bewertungen auf die Finanzierungskosten zukünftiger WEA sind noch nicht berücksichtigt. In der Projektskizze WEA.WInD-Pool (siehe auch Kapitel 2.2.9) wird die Erarbeitung von weiteren Anwendungsfeldern über den gesamten Lebenszyklus von WEA vorgeschlagen, wodurch der Nutzen des WInD-Pool für jedes einzelne Unternehmen weiter gesteigert werden kann Kooperationsvereinbarung Grundlage für den Aufbau und Betrieb des WInD-Pools bildet eine zu diesem Zweck erarbeitete und von den EVW-Projektpartnern unterzeichnete Kooperationsvereinbarung sowie die zugehörigen drei Anlagen. Die Kooperationsvereinbarung definiert die grundlegenden Regeln in der Zusammenarbeit und soll ein gemeinsames Verständnis über das Ziel der Zusammenarbeit, zu erbringende Leistungen Abschlussbericht EVW Phase

48 Darstellung der und die Vertraulichkeit von Daten und Auswertungen schaffen. Hierzu regelt die Kooperationsvereinbarung Fragen der Laufzeit, der Finanzierung, der Vertraulichkeit, der Haftung, Rechte und Pflichten sowie Kündigung und Beitritt. Die drei Anlagen der Kooperationsvereinbarung enthalten das Vertraulichkeitskonzept, den Minimaldatenkatalog sowie eine Liste der zu erstellenden Auswertungen. Die Entscheidung zum Aufbau des WInD-Pool eine Kooperationsvereinbarung dem Abschluss bilateraler Verträge vorzuziehen, wurde mit der Intention getroffen eine größtmögliche Transparenz zu gewährleisten und allen beteiligten Unternehmern gleiche und klar definierte Bedingungen zu bieten. KoV Anlage A: Vertraulichkeit Anlage B: Minimaldaten Anlage C: Auswertungen Abbildung 22: Aufbau der Kooperationsvereinbarung zum WInD-Pool Die Kooperationsvereinbarung ist diesem Bericht als Anhang A 3 beigefügt. Die wesentlichen Inhalte sind nachfolgend zusammengefasst: Gegenstand der Kooperation ist der Aufbau und Betrieb des WInD-Pool und die Nutzung der Daten zur Optimierung von Betrieb und Instandhaltung von WEA. Die Kooperationsvereinbarung ist zum 01. Oktober 2013 in Kraft getreten und ist auf einen langfristigen Betrieb des WInD-Pool ohne definiertes Ende ausgelegt. Die langfristige Finanzierung des Betriebs des WInD-Pool soll durch Dienstleistungen, spezifische Auswertungen und Auswertungen für Dritte erfolgen. Kurz und mittelfristig wird eine Finanzierung durch Förderprojekte angestrebt. Die Kosten der Datenlieferanten zur Teilnahme am WInD-Pool haben diese selbst zu tragen. Die Datenlieferanten stellen die in Anlage B der Kooperationsvereinbarung definierten Minimaldaten mindestens in halbjährlichem Rhythmus zur Verfügung. Das Fraunhofer IWES stellt die in Anlage C der Kooperationsvereinbarung definierten Auswertungen ebenfalls mindestens in halbjährlichem Rhythmus zur Verfügung. Bedingung hierzu ist eine entsprechend verfügbare Datengrundlage. Alle Beteiligten verpflichten sich zur Wahrung der Vertraulichkeit entsprechend Anlage A der Kooperationsvereinbarung. Es besteht Einvernehmen, dass weitere Partner dem WInD-Pool jederzeit beitreten können und einer Erweiterung des WInD-Pool für den Erfolg der Initiative unerlässlich ist. Eine Kündigung eines Partners kann aus wichtigem Grund mit einer Frist von sechs Monaten zum Ende eines Kalenderjahres erfolgen. Der Fortbestand der Kooperation ist hiervon nicht betroffen. Abschlussbericht EVW Phase

49 2.2.6 Datenbankmodell Darstellung der Das Datenbankschema des WInD-Pool ist als relationales Datenbankmodell konzipiert und folgt damit dem Grundsatz wiederkehrende Informationen in separate Tabellen auszulagern und redundante Daten zu vermeiden. Bei speziellem Informationsbedarf lassen sich die in verschiedenen Tabellen vorliegenden Informationen beliebig kombinieren und auswerten. Das in Abbildung 23 stark vereinfacht dargestellte Datenbankschema lässt sich entsprechend Kapitel nach den vorliegenden Datenarten unterteilen. Den zentralen Ausgangspunkt für die Verknüpfung aller weiteren Informationen bilden die Stammdaten mit der dort angesiedelten OBJECT_TAB, welche allgemein anwendbare Informationen zu Energieanlagen umfasst. Dem dort angelegten Objekt werden alle Informationen zugeordnet, die keiner spezifischen Art von Energieanlagen (z.b. WEA, PV-Anlage etc.) zugerechnet werden können. Spezifische Stammdaten zu einzelnen Objekten werden in entsprechenden Tabellen (z.b. WIND_TURBINE_TAB) abgelegt oder verknüpft. Betriebsdaten WT_MEAS_U1_TAB WT_MEAS_..._TAB Betriebsdatentabelle je Unternehmen Betriebsdatentabelle weiterer Unternehmen Stammdaten OBJECT_TAB WIND_TURBINE_TAB TURBINE_TYPE_TAB Unabhängig von der Objektart anwendbare Stammdaten Windenergieanlagen spezifische Stammdaten Stammdaten zur Beschreibung des Anlagentyps TOWN_TAB WIND_FARM_TAB GENERATOR_DESIGN_TAB Informationen zum Errichtungsort Windpark spezifische Stammdaten Kategorien möglicher Generatorkonzepte DIBT_WIND_CLASS_TAB Informationen zum Errichtungsort... Weitere Kategorien zur Klassifizierung des Anlagentyps Ereignisdaten EVENT_TAB EVENT_POSITION_TAB COST_TAB Grundinformationen zu einem Ereignis Informationen zu einzelnen Ereignispositionen Erfassung von Kosteninformationen ZEUS_PART1_ASSESSMENT_TAB RDS_PP_TAB... Zustandsbewertung nach ZEUS- Block 1 Liste möglicher Funktionen einer WEA nach RDS-PP Weitere Informationen zu Ereignissen und Ereignispositionen ZEUS_PART2_ASSESSMENT_TAB Zustandsbewertung nach ZEUS- Block 2 Abbildung 23: Stark vereinfachte Darstellung des Datenbankschemas des WInD-Pool Abschlussbericht EVW Phase

50 Darstellung der Die Betriebsdaten einer Windenergieanlage werden an den Eintrag der entsprechenden WEA angehängt. Abgelegt werden die Betriebsdaten in einer für Windenergieanlagen konzipierten separaten Betriebsdatentabelle. Die verschiedenen zu einer WEA und einem Zeitstempel vorhandenen Messarten werden dazu in separaten Spalten abgelegt, deren Bezeichnung sich nach der IEC richtet. Messarten ohne entsprechende Zuweisung, stehen in einer nicht dargestellten Rohdatentabelle für eine spätere Zuordnung zur Verfügung. Da es sich bei Betriebsdaten um Massendaten handelt, werden die Daten auf mehrere identisch aufgebaute Tabellen verteilt, um so die Handhabbarkeit zu vereinfachen und die Datenbankperformance sicherzustellen. Im WInD-Pool erfolgt die Aufteilung entsprechend der einzelnen Datenlieferanten. Als dritte Datenart lassen sich die Ereignisdaten grundlegend in Informationen zu dem eigentlichen Ereignis und in Informationen zu einer Ereignisposition unterteilen. Ein Ereignis referenziert ein in den Stammdaten angelegtes Objekt und ist damit immer einer Energieanlage zugeordnet. Eine Beschreibung des geänderten Zustands der Energieanlage erfolgt mittels ZEUS-Block 1 Entsprechend den von einem Ereignis betroffenen Funktionen/Komponenten der Energieanlage können einzelne Ereignispositionen angelegt und mittels ZEUS-Block 2 und RDS-PP beschrieben werden. Kosteninformationen lassen sich sowohl dem Ereignis als auch der Ereignisposition zuordnen. Über die dargestellten Informationstabellen hinaus kann der WInD-Pool weitere Ereignisinformationen (z.b. Materialien, Bauteilhistorien, ) aufnehmen. Die Datenstruktur und Benennung der Informationsfelder orientiert sich an den Definitionen des GSP (FGW Richtlinie TR 7 D3) Datenfluss, Import und Mapping Die Projekterfahrung zeigt, dass ein automatisierter und stabiler Datenfluss für den WInD-Pool von essentieller Bedeutung ist. Probleme beim Datenfluss sowie ein hoher Aufwand bei der Datenbereitstellung und Datenintegration wirken bei allen Projektbeteiligten demotivierend. Die Anforderungen an und das Vorgehen beim Datenfluss werden für die einzelnen Datenarten separat beschrieben. Da die Stammdaten der teilnehmenden WEA eines Unternehmens nur einmalig in die Datenbank aufgenommen werden müssen erfolgt die Eintragung manuell durch Mitarbeiter des Fraunhofer IWES. Besondere Anforderungen an die Form der Stammdaten bestehen nicht, eine Zuordnung zu den Informationsfeldern der Datenbank ist vergleichsweise einfach und ohne großen Aufwand manuell möglich. Anpassungen sind lediglich notwendig, wenn weitere WEA aufgenommen werden oder bestehende WEA außer Betrieb gehen. Zwar ist auch bei den Stammdaten eine Mapping von Informationen, beispielsweise bei der Zuordnung von Anlagentypen, erforderlich, dieses kann jedoch auf einfachem Weg außerhalb der Datenbank, beispielsweise. per Excel, erfolgen. Für eine einfachere Nachvollziehbarkeit der Stammdaten würde sich eine browserbasierte Weboberfläche zum WInD-Pool anbieten, die jedoch im Rahmen des EVW-Projektes nicht mehr realisiert werden konnte. Da Betriebsdaten regelmäßig (mindestens halbjährlich) durch die Datenlieferanten bereitgestellt und anschließend in den WInD-Pool importiert werden ist hier ein automatisierter Datenfluss zwingend erforderlich. Ein möglichst einfacher Datenimport ist möglich, wenn die Bereitstellung der Betriebsdaten entsprechend einer Vorlage im CSV-Format und unter Verwendung von Bezeichnern entsprechend IEC erfolgt. Die Praxis zeigt, dass die meisten Betriebsführungssysteme in der Lage sind Betriebsdaten im CSV-Format zu exportieren, der Aufbau der Datei lässt sich meist jedoch nicht anpassen. Der Importalgorithmus des WInD-Pool ist daher so gestaltet, dass er schnell an zusätzliche Datenformate angepasst werden kann. Damit die Betriebsdaten in der Datenbank entsprechend zugewiesen werden können ist außerdem ein einmaliges Mapping der individuellen Messartbezeichner jedes Unternehmens zu der im WInD-Pool verwendeten Bezeichnung nach IEC notwendig. Eine entsprechend Zuordnungstabelle ist in der Datenbank hinterlegt. Die mittlere Windgeschwindigkeit wird im WInD-Pool beispielweise als WNAC_WdSpd_AVG bezeichnet, der Datenexport von GEO bezeichnet sie als Windgeschwindigkeit mittl. [m/s], der von ENERTRAG als Windgeschwindigkeit [m/s]. Betriebsdaten weiterer Unternehmen lassen sich leicht integrieren. Abschlussbericht EVW Phase

51 Darstellung der Ereignisdaten sind zwar keine Massendaten, werden für den WInD-Pool aber ebenso wie Betriebsdaten regelmäßig bereitgestellt und benötigen einen zumindest teilautomatisierten Datenimport. Idealerweise erfolgt die Bereitstellung der Ereignisdaten unter Verwendung der GSP-Schnittstelle oder alternativ über ein zu diesem Zweck definiertes CSV-Format. Zur einheitlichen Beschreibung von Funktionen/Komponenten wird im WInD-Pool RDS-PP und für die Zustandsbeschreibung ZEUS verwendet. Beide Standards setzen sich in der Windbranche erst langsam durch, weshalb insbesondere bestehende Daten aber auch die meisten neu erfassten Daten entweder unter Verwendung von betreiberspezifischen Katalogen oder rein textbasiert vorliegen. Ein Datenfluss realer Daten über das GSP konnte so bisher nicht erfolgen, der Import in den WInD-Pool ist aber bereits vorbereitet. Für den Import von Ereignisdaten eines neuen Betreibers ist daher in der Regel ein aufwändiges Mapping durchzuführen. Im Rahmen der Konvertierung bestehender Daten wurde bereits eine Zuweisungsmatrix zwischen dem Ereignis-Merkmal-Schlüsselsystem (EMS) des VGB und ZEUS erstellt. Ebenso existiert ein Mapping des ENERTRAG spezifischen Kodierungssystems zu RDS-PP und ZEUS. Werden Daten weiterer Unternehmen aufgenommen, so sind weitere Konvertierungstabellen zu erstellen. Für textbasierte Instandhaltungsdaten existiert keine automatisierte Lösung. Hier müssen ZEUS und RDS-PP für jedes Ereignis manuell zugeordnet werden. Diese Arbeit ließe sich durch die Schaffung einer grafischen Anwenderoberfläche zumindest vereinfachen. Es ist festzustellen, dass sowohl Stamm- als auch Betriebsdaten für den Betrieb des WInD-Pool keine größeren Herausforderungen darstellen. Damit sich der Aufwand zum Import von Ereignisdaten weiter verringert, muss die Verbreitung von RDS-PP, ZEUS und GSP in der Windbranche weiter voranschreiten. Beteiligung beabsichtig Kontakt zu Fraunhofer IWES Prüfung durch Fraunhofer IWES Information der Teilnehmer Unterschrift der Beitrittserklärung Prüfung der Daten Daten bereit? Nein Datenaufbereitung Ja Integration in den WInD-Pool Erstellung von Auswertungen Abbildung 24: Ablauf zur Integration weiterer Datenlieferanten in den WInD-Pool Abschlussbericht EVW Phase

52 2.2.8 Technische Umsetzung Darstellung der Technisch baut der WInD-Pool auf einer Oracle-Datenbank in der Version 10g auf. Zur Gewährleistung der Datensicherheit wird die Datenbank des WInD-Pools durch das Fraunhofer IWES am Standort Kassel auf eigenen Datenbankservern betrieben. Die Aufstellung in der sogenannten Demilitarized Zone verhindert einen direkten Zugriff aus dem Internet. Auch innerhalb des Fraunhofer-IWES ist der Datenzugriff auf den, für die Administration des WInD-Pools und die Erstellung der Auswertungen, notwendigen Personenkreis begrenzt. Die Kommunikation mit beteiligten Unternehmen erfolgt im Regelfall über eine verschlüsselte und per Zertifikat abgesicherte FTPS-Verbindung. Der FTPS-Server wird ebenfalls auf Infrastruktur des Fraunhofer IWES betrieben. Betriebs- und Ereignisdaten werden durch die Betreiber auf den FTPS-Server abgelegt (Push-Modell). Alternativ kann der Datentransfer auch auf anderem Weg erfolgen. Praktiziert wird bisher der regelmäßige Download aus dem Betriebsführungssystem eines Betreibers per Webschnittstelle. Weitere noch nicht umgesetzte Möglichkeiten sind ein direkter Datenabruf aus der Datenbank des Betriebsführungssystems durch das Fraunhofer IWES, der Download von einem FTP(S)- Server oder der direkte Zugriff auf die Anlagensteuerung. Abbildung 25: Schematische Darstellung der technischen Konzeption des WInD-Pool Liegen aktualisierte Daten auf den Servern des IWES bereit, werden diese im Rahmen des Verarbeitungsprozesses zunächst in ihrer Ausgangsform archiviert, daraufhin in ein für die Datenbank lesbares Format konvertiert, als CSV-Daten erneut archiviert und schlussendlich in die Datenbank importiert, wo sie verarbeitet, verknüpft und den entsprechenden Tabellen zugewiesen werden. Die Unterteilung in mehrere Prozessschritte mit mehrfacher Datensicherung ermöglicht es eventuelle Fehler nachzuvollziehen und einzelne Schritte bei Bedarf zu wiederholen. Der beschriebene Prozess wir unter Verwendung eines IWES-internen und auf Java basierenden Frameworks realisiert. Die Analyse der Betriebsdaten erfolgt direkt auf dem Datenbankserver unter Verwendung von PL/SQL- Prozeduren und SQL-Abfragen. Zur Auswertung der Ereignisdaten wird die von IZP Dresden entwickelte Desktopsoftware RAMS-Office eingesetzt, welche per ODBC mit der Datenbank verbunden ist. Abschlussbericht EVW Phase

53 Darstellung der Für die Visualisierung der Auswertungsergebnisse und die Erzeugung unternehmensspezifischer Berichte wird die Programmiersprache Python und insbesondere die Bibliothek Matplotlib eingesetzt. Das Layout der Berichte erfolgt unter Verwendung des Textsatzsystem TeX bzw. des Softwarepaketes La- TeX. Aus den zuvor erstellen Auswertungen lassen sich so aus dem WInD-Pool unternehmensspezifische Berichte erzeugen. Der entwickelte Code wird für die Projekte Offshore~WMEP und EVW gemeinsam genutzt Aktueller Stand und Ausblick Zum Projektabschluss hat der WInD-Pool die Betriebsbereitschaft erreicht und wurde mit Daten der Verbundprojektpartner gefüllt und getestet. Integriert sind Daten der Projektpartner GEO und ENER- TRAG/Windstrom sowie Altdaten aus dem Wissenschaftlichen Mess- und Evaluierungsprogramm (WMEP), welche allerdings nur Ereignisdaten und keine Betriebsdaten umfassen. Wesentliche Voraussetzung hierfür war die Fertigstellung und Verabschiedung der Standards/Richtlinien RDS-PP und ZEUS in ihren letzten Revisionen, welche die Struktur des WInD-Pool erheblich beeinflussen und zukünftig nur noch kleinere Änderungen erwarten lassen. Mit der Ausarbeitung und dem Abschluss der Kooperationsvereinbarung über den Aufbau und Betrieb des WInD-Pool sind die rechtlichen Rahmenbedingungen geklärt und einer Aufnahme der Daten weiterer Unternehmen steht aus rechtlicher und technischer Sicht nichts im Weg. Da sich der WInD-Pool mit dem erreichten Datenumfang und den bisher erarbeiteten Anwendungsszenarien wirtschaftlich noch nicht selbst tragen kann, haben Fraunhofer IWES und IZP Dresden gemeinsam mit derzeit sieben assoziierten Industriepartnern die Projektskizze WEA.WInD-Pool (Wertschöpfung durch die Erweiterung der Anwendungsmöglichkeiten des Windenergie-Informations-Daten-Pool) zur Förderung beim BMWi eingereicht. Ziel des vorgeschlagenen Projektes ist es den weiteren Ausbau und Betrieb des WInD-Pool sicherzustellen und auf dieser Basis Anwendungsmöglichkeiten für alle Lebenszyklusphasen von WEA zu entwickeln. Neben den bereits vorliegenden Absichtserklärungen zur Teilnahme am WInD-Pool werden weitere Teilnehmer gesucht um den Datenumfang möglichst schnell zu erhöhen. Über das kurz und mittelfristige Ziel des weiteren Betriebs und Ausbau des WInD-Pool hinaus, ist langfristig eine direkte Verknüpfung mit der Datenbasis des Offshore~WMEP vorstellbar. Beide Datenbasen verfügen bereits heute über vergleichbare Strukturen. Da die Windenergie auch in anderen Ländern Europas immer stärker genutzt wird, ist langfristig ebenso eine entsprechende EU-Initiative denkbar. Eine länderübergreifende Abstimmung von Standards und Auswertungsmethoden wird u.a. durch das Fraunhofer IWES bereits im IEA Task 33 Reliability Data vorangetrieben. Abschlussbericht EVW Phase

54 2.3 Methoden und Anwendungsszenarien für Systemanalysen Zuverlässigkeitsbewertungen Übersicht Darstellung der Das wichtige Anliegen der Erhöhung der Verfügbarkeit von Windkraftanlagen war bereits das Hauptthema des Vorgängerprojekts EVW I, welches ebenfalls vom Bundesministerium für Umwelt, Naturschutz und Reaktorsicherheit gefördert worden ist. Der Verfügbarkeitsbegriff ist zentral gekennzeichnet durch die Stillstandszeiten und diese sind untrennbar verbunden mit den Zuverlässigkeitseigenschaften und Instandhaltungsmaßnahmen der Windkraftanlagen. Deshalb wurden im EVW I - Abschlussbericht die erbrachten Entwicklungsleistungen stets in ihrer Verknüpfung mit Zuverlässigkeit (Zuv) und Instandhaltung (IH) vorgestellt und diskutiert. Einerseits konnte an den aktuellen Abläufen der betrieblichen Instandhaltung der damals beteiligten Projektpartner SAG Erwin Peters GmbH und der ENERTRAG AG illustriert werden, welchen Einfluss die jeweils existierende und verwendete Datenbasis (z.b. MABI) auf die Gestaltbarkeit des RAM-Prozesses hat. So steht eine gut organisierte Zuverlässigkeitsdatenbank in direktem Zusammenhang mit den Möglichkeiten für objektiv messbare Instandhaltungs-Upgrades. Vor allem wurden darüber hinaus einige theoretische Konzepte vorgestellt zur Aufbesserung, also zur optimierenden Gestaltung der Instandhaltung. Schwerpunktverfahren waren dabei Condition Monitoring Systeme (CMS, Driftmodelle), der ökonomisch optimale Baugruppenaustausch oder die Zusammenlegung von IH-Terminen und IH-Maßnahmen. Es wurde sogar die Vision eines ganzheitlichen Instandhaltungsmanagements für WEA entwickelt, bei der die Existenz einer aussagekräftigen und empfohlener Weise auch zentralisierten Schadensdatenbank eine Voraussetzung ist. Dies blieb noch Vision, denn schon der Versuch einer Umsetzung scheiterte an der noch mangelhaften, uneinheitlichen Datenbasis. Dies war letztlich auch der Grund, weshalb eine Fortführung des EVW-Gedankens durch EVW- PHASE 2 angestrebt und dann auch bestätigt worden ist. Ein Thema in dieser zweiten Entwicklungsphase war die Modellierung und numerische Komplettierung (mit Software-Unterstützung) von Zuverlässigkeitsanalysen und Ersatzteilprognosen spezieller redundanter reparierbarer Systeme, nämlich der wichtigen Klasse der k-aus-n-systeme. Das Ergebnis: Unter sehr breiten Rahmenbedingungen können insbesondere die Zuverlässigkeit solcher Systeme berechnet als auch die Ersatzteilfrage beantwortet werden. Mit den nachstehenden Ausführungen werden derartige Bausysteme kurz erklärt, ihre Besonderheiten und auch Vorteile im Blick auf die Zuverlässigkeit erläutert und einige ihrer konkreten Auslegungen diskutiert. Es schließt sich eine Beschreibung der Systemmodellierung an und die Darstellung der Lösungsansätze unter weitgehendem Verzicht auf die mathematische Sprache. Die Ausführungen werden durch ein Beispiel begleitet, welches die Begrifflichkeiten beleuchtet soll, was aber natürlich hinsichtlich der konstruktiven Grundlagen und der verwendeten Zuverlässigkeitskennwerte sowohl vereinfacht als auch vor allem verfremdet ist. Es können daraus also keinerlei Rückschlüsse auf eventuell existierende konkrete Baueinheiten und deren Eigenschaften gezogen werden. Den Abschluss der Übersicht muss jedoch noch eine Bemerkung hinsichtlich der eigentlich angestrebten Instandhaltungsvorhaben nämlich Optimierung der Instandhaltungsstrategien zur Senkung der Kosten und/oder der Erhöhung der Verfügbarkeit bilden. Es sind aus der Literatur 1 und auch aus eigener Entwicklungstätigkeit Methoden bekannt, die bei Kenntnis erstens der Zuverlässigkeitseigenschaf- 1 Beichelt,F.: Zuverlässigkeits- und Instandhaltungstheorie, Vieweg+Teubner Verlag 1993 Abschlussbericht EVW Phase

55 Darstellung der ten von Betrachtungseinheiten und zweitens der Kenntnis der Kosten für Anschaffung und/oder Instandhaltungsmaßnahmen die Modellierung optimaler IH-Strategien gestatten. Ein einfaches Beispiel dafür: Kenntnis der Lebensdauerverteilung und Kenntnis der einerseits mit korrektiven Maßnahmen und andererseits mit präventiven Maßnahmen verbundenen Kosten erlaubt zu entscheiden, ob überhaupt und, wenn ja, wann präventive Maßnahmen ökonomisch optimal durchgeführt werden sollten. Nun ist es leider auch im Rahmen von EVW-PHASE 2 noch nicht gelungen, Hersteller, Betreiber und Instandhalter gemeinsam zu überzeugen, die Kosten nicht mehr nur als Betriebsinterna anzusehen, sondern diese ebenfalls in die zu entwickelnde Datenbank wenigstens als nicht öffentlich einpflegen zu lassen, um die genannten IH-Untersuchungen auch wirklich durchführen zu können. Deshalb wird hier im Bericht auf die Darstellung und Anwendung von Strategien verzichtet, die in Abhängigkeit der konkreten Rahmenbedingungen optimale Abläufe realisieren. Dafür waren innerhalb des Projektes keine Praxisbeispiele als Anwendungen gegeben. Es konnten nur solche IH-Untersuchungen durchgeführt werden, bei denen die Kosten keine Rolle spielen. Daher der Fokus hier auf die k-aus-n-systeme Erläuterung k-aus-n-system Unter einem k-aus-n-system versteht man ein redundantes System aus n Elementen mit der Eigenschaft, dass es genau dann intakt ist, wenn k oder mehr der n Elemente intakt sind. Mit dieser Definition ist die Standardredundanz, also ein Parallelsystem aus n Elementen, ein 1-aus-n-System. Denn dieses ist genau dann intakt, wenn das wenigstens für eines der n Elemente zutrifft. Auch ein Reihensystem mit n Elementen kann in dieser Kategorie betrachtet werden, denn es ist ein n- aus-n-system. Für diese beiden Systemtypen kann bei Verzicht auf Reparatur die Zuverlässigkeitsanalyse sehr einfach durchgeführt werden, zumindest wenn ihre Elemente unabhängig arbeiten. Doch unter dem Gesichtspunkt der Instandhaltung, also bei sofortiger Reparatur defekter Elemente im weiterhin arbeitenden System, werden die Überlegungen zu den k-aus-n-systemen mit 1 k<n tatsächlich relevant. Zur Veranschaulichung sind in den beiden folgenden Abbildungen die Darstellungen eines 2-aus-3- Systems als Zuverlässigkeitsschaltbild und als Fehlerbaum angegeben Abbildung 26: Zuverlässigkeitsschaltbild eines 2-aus-3 Systems Abschlussbericht EVW Phase

56 Darstellung der Top Event defekt 1 & & & 1 defekt 2 defekt 2 defekt 3 defekt 3 defekt 1 defekt Abbildung 27: Fehlerbaum für ein 2-aus-3 System Die obige Abbildung ist genormt als Fehlerbaum für ein 2-aus-3 System: Top Event 2 1 defekt 2 defekt 3 defekt Abbildung 28: Standardisierter Fehlerbaum eines 2-aus-3-Systems Die k-aus-n-systeme bilden eine wichtige Klasse redundanter Systeme. Dennoch ist natürlich nicht jedes redundante System ein k-aus-n-system. Ein Beispiel dafür ist die bekannte Brückenschaltung. Ein weiteres Beispiel findet man in den Beschleunigungssensoren GAM900S, die für den Einsatz in WEA s vorgesehen sind. Die sichere Überwachung soll durch eine zweikanalige Anordnung der Sensoren garantiert werden, wobei durch diverse Rücklese- und Querkontaktierungen das reine Parallelsystem noch weiter aufgebessert wird. Derartige Redundanzen können nicht direkt durch den k-aus-n-algorithmus analysiert werden, jedoch führen in solchen Fällen spezifische Ergänzungen auch zu einem einsetzbaren Tool. Die Abbildung ist dem Internetauftritt der Firma Baumer GmbH entnommen. Dort kann man auch weitere Erläuterungen zur konkreten Schaltung entnehmen. Abbildung 29: Sicherheitsauslegung beim Beschleunigungssensor GAM900S als System mit komplexem Schaltbild Abschlussbericht EVW Phase

57 Voraussetzungen bei k-aus-n-systemen Darstellung der Falls nicht anders betont, wird vorausgesetzt, dass sich die Elemente des Systems in ihrer Arbeit nicht beeinflussen bzw. das Versagen eines Elementes nicht das Versagen anderer Elemente nach sich zieht. Das heißt es werden nur unabhängige Systeme betrachtet. Dies ist für die (zumindest für die einfach gehaltenen) theoretischen Modellierungen eine zwingende Voraussetzung. Die später ebenfalls vorgestellte simulative Auswertung kann darauf aber verzichten, wenn entsprechende Anpassungsarbeiten erfolgen. Wie bei jedem technischen System wird auch hier die Wahrscheinlichkeit (Wkt) für den Systemausfall durch diejenigen der Elemente geprägt. Lebensdauerinformationen für die n Elemente müssen also vorliegen. Es werde der einfache (und praktisch nicht sehr bedeutsame) Fall, dass die Ausfall-Wkt s der Elemente zu einer festen Zeit gegeben sind, nicht weiter betrachtet. Das heißt dann aber, dass die Verteilungsfunktionen F j (j=1..n) der Elementelebensdauern bekannt sind. Gesucht ist dann F, die Verteilungsfunktion des Systemausfalls, oder einige ihrer Werte. Weiter ist eine Planungszeit t P vorzugeben, bis zu der die Gefahr des Systemausfalls interessiert. Es bedeute E j (j=1,..,n) die (zufällige) Lebensdauer des Elements j. Der Wert der Verteilungsfunktion F j (t) zur Zeit t ist dann F j (t)=p(e j t), also gleich der Wkt, dass Element j bis t ausgefallen ist. Analog gilt F(t)=P(S t), wenn S die Systemlebensdauer ist. Oft verwendete und im Programm RAMS-Office NG derzeit nutzbare Verteilungsfunktionen sind die Exponentialverteilung F(t) = = (t>t 0 ) Weibullverteilung F(t) = = (t>t 0 ). Aber auch andere parametrische Verteilungen könnten über ihre Parameter zur Beschreibung des Ausfallverhaltens vorgegeben werden. Manche der gängigen analytischen Berechnungsverfahren sind nur anwendbar oder zumindest wesentlich einfacher einsetzbar, wenn exponentialverteilte Lebensdauern vorliegen. Dem kann man natürlich folgen, muss dann aber gewisse Genauigkeitsverluste in Kauf nehmen. Auch hier gilt das oben schon Gesagte: Simulationsauswertungen sind auf derartige Modellierungsbeschränkungen nicht angewiesen und liefern dadurch, die der Realität besser entsprechen. Bei der Auswertung auf der Basis mathematischer Modelle versagen manche Algorithmen, falls durch die Vorgabe der Planungszeit t P die Funktionswerte F j (t P ) gleich null oder eins sind. Dies muss also geprüft und durch geeignete Modifizierungen abgefangen werden. Das Ergebnis Ausfall-Wkt des Systems zur Zeit t P hängt von weiteren Vorgaben ab, die den konkreten Betrieb des Systems kennzeichnen. Die Betriebsorganisation wird unterschieden bezüglich Reserveart, und dabei heißer Reserve (alle Elemente, auch die n-k nicht sofort benötigten, werden von Anfang an betrieben); kalter Reserve (nur k Elemente werden betrieben, alle anderen warten im Ausgangszustand Reparaturmöglichkeit, und dabei die ausgefallenen Elemente werden nicht repariert; ausgefallene Elemente werden sofort nach Ausfall repariert, Abschlussbericht EVW Phase

58 Darstellung der wobei noch zu unterschieden ist, ob im Fall mehrerer defekter Einheiten alle gleichzeitig oder nacheinander je nur eine repariert werden kann. Schließlich werden gelegentlich Ausfälle beobachtet, die sich nicht nur auf einzelne Elemente auswirken, sondern sofort auf das Gesamtsystem. Trotz der Redundanz wird durch derartige Einflüsse das gesamte System zum Erliegen gebracht (Common Cause Failure, CCF). Die Häufigkeit solcher CCF wirkt sich natürlich ebenfalls auf die Systemausfallwahrscheinlichkeit aus. Eine gute Übersicht zu den unterschiedlichen Betriebskonfigurationen für ein k-aus-n-system liefert das Fenster eines Analyseprogrammes. Die Beschreibungen sind hier als Eingabeoptionen deutlich zu erkennen. Abbildung 30: Betriebsvarianten eines k-aus-n-systems im Analysetool Abschlussbericht EVW Phase

59 Analysen mit k-aus-n-systemen Fall 1: Heiße Reserve, ohne Reparatur Darstellung der Hier sind die Elementeausfall-Wkt s aus den Verteilungsfunktionen bereitzustellen (wenn diese Werte nicht direkt vorgegeben sein sollten) und auf dieser Basis sind die Funktionswerte einer Binomialverteilung zu berechnen. Dies ist bis auf die Bewältigung numerischer Effekte keine problembehaftete Aufgabe. Fall 2: Kalte Reserve, ohne Reparatur Hier und auch bei den Betriebsbedingungen mit Reparatur müssen zur Modellierung die Verteilungsfunktionen der Elementelebensdauer verwendet werden. Erst einmal könnten diese Verteilungsfunktionen prinzipiell von Element zu Element variieren. Dann aber müsste schon zu Beginn festgelegt werden, welche k der n Elemente zuerst arbeiten und in welcher Reihenfolge die übrigen bei Reservebedarf in Betrieb genommen werden. Das ist eine praktisch sehr unreale Situation. Daher wird die für die Praxis kaum einschränkende Voraussetzung getroffen: Die Lebensdauerverteilungen der Elemente sind alle gleich, das heißt alle Elemente sind baugleich und ihre Einsatzbedingungen sind auch gleich. In diesem Fall 2 wird also erst bei Versagen eines der k arbeitenden Elemente ein Reserveelement zugeschaltet. Das System ist intakt, bis alle Reserveelemente aufgebraucht sind. Die Berechnung der Wahrscheinlichkeit des Systemausfalls führt zur Auswertung von Faltungsintegralen. Das ist erstens beinahe immer nur mit numerischen Mitteln möglich. Und zweitens kommen zusätzlich noch Probleme hinzu durch die Notwendigkeit, mit Restlebensdauerverteilungen arbeiten zu müssen. Nur im Fall, dass alle Elemente eine gleiche Exponentialverteilung als Lebensdauerverteilung besitzen, lässt sich die Auswertung mit Hilfe einer (eventuell verschobenen) Erlangverteilung geschlossen durchführen. Aber auch hier gilt wieder: Wenn man von vornherein die Auswertung durch Simulationsrechnungen durchführt, kann der Zwang zu exponentialverteilter Lebensdauer entfallen. Auch die Voraussetzung zu gleichen Lebensdauerverteilungen könnte man wenn ein solcher Fall angefordert werden sollte ohne allzu große Programmänderungen streichen. Fall 3: Heiße oder kalte Reserve, mit Reparatur Defekte Elemente werden bei dieser Betriebsart repariert (getauscht, gewartet, ) ohne Unterbrechung der Systemarbeit. Neben der Lebensdauerverteilung für die Elemente muss hier also noch eine Angabe zur die Dauer der Reparatur (Reparaturzeitverteilung) vorliegen. Beide Verteilungen werden aus Gründen der Modellvereinfachung meist als Exponentialverteilungen angesetzt. Wie in den beiden ersten Fällen ohne Reparatur kann das arbeitende k-aus-n-system unterschiedliche Systemzustände X t = Anzahl der defekten Elemente zur Zeit t annehmen. Und zwar können X t =j der n Elemente zur Zeit t defekt sein (j = 0, 1,..., n-k). Nur erfolgte bisher ohne Reparatur mit wachsender Zeit der Wechsel von einem zum anderen Zustand allein in wachsender Richtung j. Jetzt, mit Reparatur, kann X t als Funktion der Zeit auch fallen. Daher sind nun andere mathematische Modelle gefragt. Zur Beschreibung der Systemausfallwahrscheinlichkeit wird oft ein einfacher Markowprozess, ein Geburts-Todes-Prozess, herangezogen. Dieser kann durch den Grafen der folgenden Abbildung veranschaulicht werden. Abschlussbericht EVW Phase

60 Darstellung der 0 1 n-k-1 n-k... n n-k Abbildung 31: Markow-Graph Dazu ein paar Bemerkungen. In den Kreisen ist der Systemzustand vermerkt, anfangs gleich 0 (das heißt 0 defekte Elemente) und am Ende gleich n-k+1, was n-k+1 defekte Elemente und damit Systemausfall heißt. Über (unter) den Pfeilen sind die Übergangsraten (oder Übergangs-Wkt s) von einem in den anderen Zustand angegeben. Konkretes Beispiel: Zum Zustand 1 kommt das System aus dem Zustand 0 durch Ausfall eines der betriebenen Elemente; die zugehörige Rate 0 hängt ab von der Anzahl der anfangs arbeitenden Elemente. Oder das System gelangt dahin aus dem Zustand 2 durch Beendigung der Instandsetzung eines defekten Elements; die zugehörige Übergangsrate 0 hängt ab von der Zeitdauer der Reparatur und der Möglichkeit der eventuell gleichzeitigen Reparatur der zwei defekten Elemente. Es bezeichne nun die Verteilung der Lebensdauer F(t) = e t und die Verteilung der Reparaturzeit G(t) = e t. Die im Modell zugelassenen Unterscheidungen bezüglich der Betriebsart heiße Redundanz (Reserveelemente arbeiten ständig mit) kalte Redundanz (Reserveelemente arbeiten erst bei Bedarf) bezüglich der Reparaturabfolge parallele Reparatur (defekte Elemente gleichzeitig reparieren) serielle Reparatur (defekte Elemente nicht gleichzeitig reparieren) führen zu den folgenden vier Varianten (Var 1-4) hinsichtlich der Übergangsraten: Abschlussbericht EVW Phase

61 Darstellung der Var 1: Ausfall heiße Reserve, Reparatur parallel = Rep. aller Defekte gleichzeitig ) 0 =n, 1 =(n-1),.., n-k-1 =(k+1), n-k =k 1 =1, 2 =2,.., n-k =(n-k) Var 2: Ausfall heiße Reserve, Reparatur seriell = Rep. der Defekte nur nacheinander ) 0 =n, 1 =(n-1),.., n-k-1 =(k+1), n-k =k 1 =, 2 =,.., n-k = Var 3: Ausfall kalte Reserve, Reparatur parallel = Rep. aller Defekte gleichzeitig ) 0 =k, 1 =k,.., n-k-1 =k, n-k =k 1 =1, 2 =2,.., n-k =(n-k) Var 4: Ausfall kalte Reserve, Reparatur seriell = Rep. der Defekte nur nacheinander ) 0 =k, 2 =k,.., n-k-1 =k, n-k =k 1=, 2 =,.., n-k = Fall 4: Common Cause Failure In der Modellierung des k-aus-n-systems wurden auch Common Cause Failure (CCF) berücksichtigt. CCF sind solche Fehlerereignisse, die gleichzeitig alle Elemente der k-aus-n-redundanz zum Erliegen bringen. Sie schalten damit trotz der Redundanz sofort das gesamte System aus. CCF treten zwar sehr selten auf, haben dennoch aber für die Systemzuverlässigkeit eine enorme Auswirkung. In Ermangelung besserer Techniken wurde dabei der auch sonst oft verwendete Ansatz mittels eines ß-Faktors benutzt. Dieser Faktor gibt den Anteil derjenigen beobachteten Systemausfälle an, die durch gleichzeitigen Ausfall aller Elemente hervorgerufen werden. Entsprechend ist (1-ß) der Anteil der normalen Systemausfälle, die durch den Ausfall eines einzigen Elements (eben des letzten in der jeweiligen Redundanzstruktur) entstehen. Eine Aufteilung aller Fehler in die beiden Klassen CCF und nicht CCF erlaubt, das Versagen des gesamten Systems als Reihenschaltung zu modellieren. Common Cause Failure Ausfallwkt q 1 normale Fehler (kein CCF) Ausfallwkt q 2 Abbildung 32: Common Cause Failure Abschlussbericht EVW Phase

62 Man beachte, dass beide Fehlerarten disjunkt sind. Darstellung der Die Systemausfall-Wkt P(S) unter Berücksichtigung von CCF kann daher angesetzt werden als P(S-Ausfall mit CCF) = P(S-Ausfall nur CCF) + P(S-Ausfall ohne CCF) =: q 1 + q 2. Kommentar 1 (Berechnung für CCF von q 1 ): Nach Definition des ß-Faktors gilt q 1 = ß P(alle Elemente fallen gleichzeitig aus) = ß [1 - (1-p 1 ) (1-p 2 )... (1-p s )]. Die Wkt p i sind dabei die Ausfall-Wkt s der Elemente. Bei heißer Reserve gilt s=n und bei kalter Reserve s=k. Der Ansatz gilt unabhängig davon, ob für das System Reparatur vorgesehen ist oder nicht. Kommentar 2 (Berechnung von k-aus-n System ohne CCF q 2 ): Die Berechnung der Wkt eines Systemausfalls ohne CCF erfolgt nach Methoden, die bisher bereits kurz skizziert worden sind. Folglich lautet der Ansatz hier q2 = (1-ß) P(S-Ausfall ohne CCF). Insgesamt folgt P(S-Ausfall mit CCF) = ß [1 - (1-p 1 ) (1-p 2 )... (1-p s )] + (1-ß) P(S-Ausfall ohne CCF). Mit diesem Ansatz werden die Grenzfälle richtig wiedergegeben. So gelten für ß=0 : P(S-Ausfall mit CCF) = P(S-Ausfall ohne CCF), ß=1 : P(S-Ausfall mit CCF) = 1 (1-p 1 ) (1-p 2 )... (1-p s ). (ß=1 heißt, es treten nur CCF auf. Nur CCF wiederum heißt, dass das System bei kalter Reserve ausfällt, wenn eines der k Elemente ausfällt, die anfangs arbeiten. Die Ausfall-Wkt eines solchen Reihensystems wird gerade durch die obige Gleichung wiedergegeben.) Weiter für alle p i =0 : P(S-Ausfall mit CCF) = (1-ß) P(S-Ausfall ohne CCF) = 0, alle p i =1 : P(S-Ausfall mit CCF) = ß + (1-ß) P(S-Ausfall ohne CCF) = 1. Abschließende Bemerkung: CCF-Fehler üben bei üblichen Systemauslegungen einen erheblichen Einfluss auf die Systemwkt P(S) aus. Dieser Einfluss ist umso gravierender, je stärker die Redundanz des Systems ist. Abschlussbericht EVW Phase

63 Beispiel Generatorkühlung Darstellung der Als Beispiel wird die Generatorkühlung einer WEA herangezogen. Es handelt sich dabei um ein technisch realisiertes Beispiel, welches aber von vornherein im Detail vereinfachte und auch bewusst verfremdete Situationen verwendet. Das trifft insbesondere auf die später in die Diskussion gebrachten Zuverlässigkeitseigenschaften der angesprochenen Bauteile zu. Die Generatorkühlung wird über einen Ölkreislauf, bestehend aus Pumpen, Wärmetauscher und diversen Leitungen, Filtern u.ä. realisiert. Das von einer einzigen Pumpe unter Volllastbetrieb geförderte Öl reicht zur Kühlung des Generators aus. Wenn die Ölförderung nicht mehr ausreicht, also die Pumpen überhaupt nicht mehr oder nicht mehr in vollen Umfang fördern, erkennt dies ein Durchflussmesser und schaltet die WEA sofort ab. In Abbildung 33 ist eine Prinzipskizze dieser Generatorkühlung zu sehen. Wie in der Realität soll hier mit dem k-aus-n-tool nicht vordergründig zur Zuverlässigkeitsbewertung einer einmal vorhandenen Konstruktion gearbeitet werden, sondern es soll vor allem als Hilfsmittel zur Zuverlässigkeits-Abschätzung im Vorfeld dienen. Abbildung 33: Prinzipschaltbild Generatorkühlung Zuverlässigkeitskennwerte Folgende Lebensdauer-Kennwerte sind für eine Pumpe unter Volllast seitens des Pumpenherstellers ermittelt und angegeben worden. X sei dabei die Lebensdauer. EX = LD-Erwartungswert = MTBF = DX = LD-Standardabweichung = 180 Tage 110 Tage Da aus Erfahrung die Lebensdauer bauähnlicher derartiger Pumpen zweiparametrisch weibullverteilt ist, wird auch hier mit diesem Verteilungstyp gearbeitet. Zu den beiden vorgegebenen Verteilungsmomenten gehören (gerundet) die Verteilungsparameter (Berechnung zum Beispiel mit RAMS-Office NG ) ß = 1,7 T = 200. Abschlussbericht EVW Phase

64 Darstellung der Für die Berechnung der System-Zuverlässigkeit wird folglich die Weibullverteilung F Voll (t) = Weibull(t; 1.7; 200; 0) = e ( t. ) als LD-Verteilung der Pumpen unter Volllast verwendet. Die LD-Maßeinheit ist dabei immer Tage. Spätere Analysen untersuchen zusätzlich die Situation bei einer nur 50%-igen Pumpenbelastung. Dazu die weitere Mitteilung des Herstellers: Bei halber Last ändern sich die oben genannten Zuv- Kennwerte zu EX Halblast = LD-Erwartungswert = 320 Tage DX Halblast = LD-Standardabweichung = 130 Tage Der Verteilungstyp bleibt weiterhin zweiparametrisch Weibull. Zu diesen neuen Verteilungsmomenten gehören die gerundeten Verteilungsparameter (Berechnung wieder mit RAMS-Office NG ) ß = 2,7 T = 360. Zur Berechnung der System-Zuverlässigkeit bei halber Belastung der Pumpen wird daher die Weibullverteilung F Halb (t) = Weibull(t; 2.7; 360; 0) = e ( t, ) als LD-Verteilung der Pumpen verwendet. Die LD-Maßeinheit bleibt Tage. Zielstellung für die Kühlung: Mit 99% Sicherheit soll das Kühlsystem 20 Jahre lang fehlerfrei arbeiten. Fehlerfrei arbeiten heißt nicht, dass dieses Kühlsystem 20 Jahre lang ununterbrochen arbeiten muss. Natürlich sind Stillstandszeiten der WEA wegen allgemeiner Wartungsarbeiten akzeptiert, in die nötigenfalls auch Auswechselungen von Pumpen oder andere Wartungen am Kühlsystem durchgeführt werden. Ein Wartungszyklus ist auf 1/3 Jahr = 4 Monate =120 Tage festgelegt. Falls in den folgenden konkreten Situationen mehrere Pumpen in Redundanz auftreten gilt: Die Pumpen arbeiten immer in heißer Redundanz, weil der Start einer kalten Reservepumpe öfters misslingt. Noch eine Vereinfachung der Diskussionen: Zu den Wartungsterminen werden laut Anweisung alle Pumpen gewechselt, also auch die nicht defekten. Im Hintergrund dieser Anweisung steht die berechnete Wahrscheinlichkeit der Überlebensdauer einer Pumpe in einem zweiten Wartungszyklus. Eine Restlebensdaueranalyse liefert dafür 0,61, eine Wahrscheinlichkeit, die beinahe doppelt so groß wie im ersten Zyklus. Abschlussbericht EVW Phase

65 Rechenbeispiele: 1. Ohne Reparatur: Darstellung der Eine Pumpe allein (die zwar die Kühlleistung erbringen würde) fällt in der Betrachtungszeit (Zeitintervall zwischen zwei Wartungen) mit der Wkt. ) P(E 1 120) = Weibull(120; 1.7; 200; 0) = e ( = 0,343 aus. Ein 1-aus-1-System besitzt also eine deutlich zu geringe Zuverlässigkeit. Auch für ein 1-aus-2-System (einfache Redundanz) ist wegen der Ausfallwahrscheinlichkeit P(E E 2 120) = 0,117 die System-Zuverlässigkeit immer noch viel zu gering. Erst ein 1-aus-5-System würde die geforderte Zuverlässigkeit erreichen, was aber konstruktiv nur schwer hinnehmbar ist. Es muss nicht betont werden, dass z.b. eine 2-aus-3-Redundanz (also k>1) vorerst nicht näher diskutiert zu werden braucht. Erstens kann man damit die Zuverlässigkeit ebenfalls nicht erreichen. Es gilt P(2 von 3 Pumpen fallen aus bis t=120) = 0,273. Vor allem aber hätte eine solche Konstruktion keinen Sinn, da ja bereits eine einzige Pumpe die erforderliche Förderleistung erbringt. Zusammenfassung: Angenommen, das Auswechseln defekter Pumpen kann nicht bei laufender WEA erfolgen und die Pumpen sollen deshalb im Fall ihres Versagens nur zu den ohnehin geplanten Wartungsfristen gewechselt werden. Dann kann mit einer technisch vertretbaren Redundanz die geforderte System-Zuv mit der vorgegebenen Pumpen-Zuverlässigkeit nicht erreicht werden. Mit Reparatur (parallel): Eine sofortige Reparatur wird in Betracht gezogen. Dafür ist natürlich vorauszusetzen, dass erstens die Information Pumpe defekt eine Basisstation erreicht, von wo aus dann sofort reagiert werden kann, und dass schließlich die Reparatur bei laufendem Betrieb der WEA auch tatsächlich ausgeführt werden kann. Hierfür müssen entsprechende Absperrventile vorhanden und funktionsfähig sein bzw. durch Bewegung funktionsfähig gehalten werden. Die Reparatur auch mehrerer Pumpen kann dann gleichzeitig erfolgen (parallele Reparatur), falls dies erforderlich würde. Eine Einbindung von Reparaturen in die Modellierung ist natürlich nur bei Redundanz bzgl. des Pumpensystems sinnvoll. Reparatur im Sinne der Modellierung wäre ja zwecklos, wenn bei Ausfall einer Pumpe das Kühlsystem selbst nicht mehr in Betrieb ist. Abschlussbericht EVW Phase

66 Darstellung der Es wird im Rahmen der Beispieldiskussion deshalb vorerst angenommen, dass die Reparaturzeit t R =5 Tage beträgt. Nochmals: 5 Tage bedeutet nicht, dass der Kühlkreislauf 5 Tage still liegt. Sondern: Bei laufender WEA benötigt der nicht bediente Pumpenstrang (einer von drei) zu seiner Wiederinbetriebnahme im Mittel 5 Tage (Lieferzeit der Pumpe, Arbeitsvorbereitung, Organisation evtl. weiterer Maßnahmen an der Anlage, ) in der Hoffnung, dass in dieser Zeit nicht der Ausfall noch weiterer Pumpen den Kreislauf zum Erliegen bringt. Damit kann die Zuverlässigkeits-Auswertung mit Reparatur erfolgen. Folgende Werte ergeben sich mit Hilfe der benannten Software: P(1-aus-2-System mit Rep t R =5 fällt aus bis t=120) = 0,013. P(1-aus-3-System mit Rep t R =5 fällt aus bis t=120) = 0,0004. Zusammenfassung: Wenn das Auswechseln defekter Pumpen bei laufender WEA erfolgen kann, wird bei einer als konstant angenommenen Reparaturdauer von t R =5 Tagen durch eine 1-aus-3-Redundanz die geforderte System- Zuverlässigkeit sogar klar überboten. Zwei weitere Aspekte sind jedoch zusätzlich noch in die Bewertung einzubeziehen. Erstens kann je nach Einsatzbedingungen (Offshore) und Ersatzteilverfügbarkeit eine Reparaturdauer t R =5 Tagen viel zu optimistisch sein. Und zweitens sind bislang auch noch keine Common Course Failure (CCF) berücksichtigt worden. Offshore-Bedingungen ohne CCF: Unter Offshore-Gegebenheiten wird der Ansatz einer exponentialverteilten Reparaturzeit mit dem Mittelwert t R =30 verwendet. Die Systemberechnung liefert dann P(1-aus-3-System mit mittl. Rep t R =30 fällt aus bis t=120) = 0,007. Also wird auch jetzt weiterhin die geforderte System-Zuv erreicht. Viel Luft zu 0,01 bleibt allerdings nicht mehr. Und weil auch Unsicherheiten hinsichtlich Pumpen-Zuverlässigkeit und Reparaturzeit mitschwingen, wird auch in der Praxis noch etwas weiter diskutiert. Nämlich: Wenn also auf jeden Fall 3 Pumpen benötigt werden, wäre auch ein 2-aus-3-System eine bedenkenswerte Variante der Systemauslegung. Denn die Pumpen müssten dann nicht mehr unter Volllast arbeiten, sondern für jede ist nur noch 50% Förderleistung erforderlich. Die für diese Betriebsart erforderlichen Zuverlässigkeits-Kennwerte der Pumpen wurden oben ( Zuverlässigkeitskennwerte ) zusammengestellt. Abschlussbericht EVW Phase

67 Darstellung der Hier zur Erinnerung nochmals die Weibullverteilung der Lebensdauer der Pumpen unter halber Belastung t, ) F Halb (t) = Weibull(t; 2.7; 360; 0) = e (. Der Wert der Ausfall-Wkt des Systems ergibt sich zu P(2-aus-3-System, Halblast, mittl. Rep t R =30, Ausfall bis t=120) = 0,0035, er konnte also nochmals um etwa die Hälfte gesenkt werden. Zusammenfassung: Das 2-aus-3-System besitzt durch die geringere Belastung bei den vorgegebenen Pumpen- Zuverlässigkeiten eine niedrigere Ausfallgefahr als das erstangesetzte 1-aus-3-System. Weitere Vorteile der 2-aus-3-Redundanz zeigen sich, wenn Common Course Failure (CCF) berücksichtigt werden. Offshore-Bedingungen mit CCF, ß=0,01: Der Wert des 2-aus-3-Systems statt des erstangesetzten 1-aus-3-Systems zeigt sich weiterhin bei zusätzlicher Beachtung von CCF. Es wird zwischen Herstellern und Betreibern ein ß-Faktor von ß=0,01 vereinbart. Es wird also angenommen, dass rund einer von 100 Pumpenausfällen durch einen CCF verursacht wird, durch den dann eben nicht nur eine, sondern gleich alle drei Pumpen ausfallen. Dies könnte z.b. ein Kurzschluss in der zentralen Versorgung oder Steuerung sein. Nochmals zurück zum 1-aus-3-System, welches ohne CCF eine Ausfall-Wahrscheinlichkeit von 0,007 besitzt (s. Absatz 3). Mit CCF beim oben genannten ß-Faktor erhält man dagegen P(1-aus-3-System mit mittl. Rep t R =30 fällt aus bis t=120, mit CCF) = 0,014, also fast die doppelte Ausfall-Wahrscheinlichkeit, mit der vor allem die Zielstellung nun nicht mehr erfüllt werden kann. Im Fall des 2-aus-3-Systems dagegen wird zwar die bisherige Ausfall-Wkt 0,0035 bei Beachtung der CCF auch größer, allerdings P(2-aus-3-System, Halblast, mittl. Rep t R =30, Ausfall bis t=120, mit CCF) = 0,0053 zeigt, dass die Zielvorgabe für das System eingehalten wird Zusammenfassung und Einordnung 2-aus-3-Systeme können bei vorgegebenen Elemente-Zuverlässigkeiten unter verschiedenen Blickwinkeln günstigere Zuverlässigkeits-Eigenschaften besitzen als andere Redundanzsysteme. Im konkreten Anwendungsfall der Generatorkühlung kommt noch Folgendes hinzu. Selbst im Fall eines Fehlers mit WEA-Abschaltung als Konsequenz (das ist bislang der gleichzeitige Defekt zweier Pumpen) könnte die verbleibende dritte Pumpe auf Volllast hochgefahren werden, was kühltechnisch ausreicht! Damit würde so die Kosten und das größere Gewicht oder die Maße entsprechend leistungsfähiger Pumpen dem nicht entgegenstehen, ein weiterer Zuverlässigkeitsgewinn der Kühlanlage erzielt werden. Abschlussbericht EVW Phase

68 Darstellung der Dieser berechnet sich als die Wahrscheinlichkeit, dass die Restlebensdauer der dritten Pumpe unter Volllast größer ist als t 2 -t 1. Dabei ist t 1 diejenige Zeit, zu der neben einer ersten in Reparatur befindlichen Pumpe auch eine zweite Pumpe ausfällt. Und t 2 ist die Zeit, zu der die Reparatur der ersten der beiden defekten Pumpen beendet ist. Dieser Zuverlässigkeitsgewinn spielte in den obigen Zahlenbeispielen noch keine Rolle und wird auch jetzt nicht durch numerische Beispiele untersetzt. Zurück zur Praxis: Die Errichtung von k-aus-n Systemen mit redundanten Einheiten lohnt sich vor allem dort, wo die Kosten (analog die Sicherheitsrisiken) eines Systemausfalls entsprechend hoch sind neben der Generatorkühlung sind z.b. Seewasserpumpen bei Offshore-Plattformen ein typisches Beispiel dafür. Umgekehrt sind die Kosten für Standardbauteile in Anschaffung und Wartung häufig so niedrig, dass sich der Einbau redundanter Elemente bereits lohnt. Außerdem ist in der Praxis zu beachten, dass Schwachstellen an anderen Stellen (Anschaltung der Steuerung, einfach vorhandene Bauteile im Funktionskreislauf, Stromversorgung aber auch Fehlermöglichkeiten bei der Instandhaltung usw.) die Effekte der Redundanz nicht aufheben dürfen. Dies kann erreicht werden, wenn ein gemeinsames Verständnis von Funktions- und Fehlfunktionszusammenhängen bei allen an der Entwicklung und Instandhaltung beteiligten Verantwortungsbereichen vorliegt. Aus kaufmännischer Sicht (s. auch folgender Abschnitt) kann die Situation jedoch völlig anders eingeschätzt werden: Redundanz wird erkauft, indem die Anlage insgesamt komplexer ausgeführt wird, d.h. es müssen mehr Elemente gewartet und ggf. auch mehr Ersatzteile eingekauft werden. Ein System, welches eine hohe Sicherheit gegen Totalausfall bietet, kann aus Sicht der IH verheerend eingestuft werden, was die Häufigkeit systemunkritischer Ausfälle angeht. Ursache: Es sind schlicht mehr Elemente verbaut als bei einem unsicheren System mit einfacher Ausführung. Müssen für ein System Zuverlässigkeitsnachweise für Kunden oder Managemententscheidungen erbracht werden, sind beide Kriterien in geeigneter Form einzubeziehen. Die Möglichkeiten dafür reichen z.b. durch eine Einteilung der Fehlerauswirkungen in Fehler- oder Störungsklassen bis hin zu einer systematischen funktionalen Sicherheitsanalyse. Abschlussbericht EVW Phase

69 2.3.2 LCC (Life Cycle Costs) Darstellung der Die Analyse und Prognose von Lebenszykluskosten ist insbesondere für langlebige Produkte wie es Windenergieanlagen sind, eine wichtige Aufgabe und eine besondere Herausforderung. Grundlegende Ausführungen zu den Begriffe, Verfahren und Analyseschritten einer LCC-Betrachtung sind in der Norm DIN EN : Zuverlässigkeitsmanagement, Teil 3-3: Anwendungsleitfaden - Lebenszykluskosten (aktuelle Fassung vom September 2004) zu finden. Hier werden die grundlegenden Begriffe wie folgt definiert: Lebenszyklus: o Zeitintervall zwischen der Konzipierung und der Aussonderung eines Produktes. Lebenszykluskosten: o Kumulierte Kosten eines Produktes über seinen Lebenszyklus Ermittlung der Lebenszykluskosten: o Prozess der wirtschaftlichen Analyse zur Abschätzung der Lebenszykluskosten eines Produktes über seinen Lebenszyklus oder einen Teil davon Das unmittelbare Ziel von LCC-Untersuchungen ist es, möglichst umfassend und genau die Kosten eines Produktes über seinen gesamten Lebenszyklus oder Teile davon vorhersagen bzw. zu berechnen. Konkrete praktische Anwendungsfälle für diese Methodik sind u.a.: Bewertung von Alternativen (bezüglich Beschaffung und Aussonderung) Abschätzung der Rentabilität von Produkten, Prozessen und Projekten Identifizierung von Kostentreibern für technische Systeme und deren Teilsysteme und Bewertung von möglichen Verbesserungen langfristige Finanzplanung Kalkulation von Serviceverträgen. Der erste Schritt der Analyse ist die Aufgliederung des Lebenszyklus der Betrachtungseinheit in einzelne Phasen. In der genannten Norm werden folgende prinzipielle Phasen genannt: a) Konzept und Definition, b) Entwurf und Entwicklung, c) Herstellung, d) Einbau (Installation / Einrichtung), e) Betrieb und Instandhaltung, f) Entsorgung Im Rahmen des Förderprojektes wurde nur die Phase Betrieb- und Instandhaltung betrachtet. Aber auch hier war es schwierig an konkrete Kosteninformationen heranzukommen. Das lag zum einen daran, dass Kostendaten aktuell kaum mit technisch orientierten Instandhaltungsdaten verknüpft sind. Die Kostenabrechnung erfolgt in der Regel in separaten kaufmännischen IT-Systemen. Es ist aber möglich die verschiedenen IT-Systeme über gemeinsame Schlüsselfelder zu verknüpfen. So z.b. wurde im Rahmen des Projektes begonnen die bei der ENERTRAG verwendeten Softwarelösungen Powersystem und Navision über eine Auftragsnummer zu koppeln. Zum anderen sind Instandhaltungskosten, die im Rahmen von Fullservice-Verträgen entstehen, für die Betriebsführungsunternehmen nicht zugänglich. Nur wenn der Herstellerservice ganz oder teilweise durch eigene Servicebereiche oder herstellerunabhängige Serviceunternehmen ersetzt wird, ist es ge- Abschlussbericht EVW Phase

70 Darstellung der genwärtig möglich an Kosteninformationen heranzukommen. Hie ist unbedingt ein besserer Informationsaustausch zwischen Anlagenherstellern und Anlagenbetreibern notwendig. Auf Grund der genannten Probleme konnten innerhalb des Vorhabens nur grundsätzliche LCC- Betrachtungen unter Verwendung von Expertenabschätzungen durchgeführt werden. Für die LCC- Analyse werden u.a. folgende Vorgaben bzw. Eingangsparameter benötigt: Systemstruktur Kostenstruktur mit Unterscheidung nach o Einmalkosten (Anschaffung, Außerbetriebnahme ) o Zyklischen Kosten (Versicherung, Abschreibung, Zinsen ) o Kosten für die präventive Instandhaltung o Kosten für die korrektive Instandhaltung Zuverlässigkeitsparameter für die relevanten Teilsysteme der korrektiven Instandhaltung Zyklen für die präventive Instandhaltung Aufwendungen für die einzelnen Kostenarten (Personal, Material, ) Als Ergebnis von Expertengesprächen wurde die in der nachfolgenden Abbildung grundsätzliche LCC- Struktur erstellt. Diese ist natürlich nur als Diskussionsvorschlag anzusehen und muss zusammen mit der Praxis weiter entwickelt werden. Ein Ansatz bezüglich der weiteren Detaillierung der korrektiven Kosten, ist eine Unterteilung unter Nutzung der RDS-PP-Struktur. Dafür kann auch die im Vorhaben EVW I erstellte FMEA-Struktur genutzt werden. Allerdings wird die Strukturierungstiefe von RDS-PP in vielen Fällen nicht ausreichen. Hier sind dann konkrete Instandhaltungsobjekte (Kleinste tauschbare Einheiten = KTE) hinzuzufügen. Wenn es gelingt, die genannten Probleme und Aufgaben zu lösen, können über systematische LCC- Betrachtungen im Anwendungsfall der Windenergieerzeugung u.a. folgende Entscheidungsfelder unterstützt werden: Optimierung der Nutzungsdauern von WEA und deren Komponenten Wirtschaftlichkeitsbetrachtungen für Service-Angebote Aufdeckung und Verringerung von Kostentreibern Rentabilitätsbetrachtungen für geplante Windparks Abschlussbericht EVW Phase

71 Darstellung der Abbildung 34: Vorschlag für WEA-LCC-Basisstruktur Abbildung 35: Auszug aus FMEA-Struktur als Basis für Detaillierung der korrektiven Kosten Abschlussbericht EVW Phase

72 Darstellung der Abbildung 36: Simulierte Kostenprognose für WEA-Teilsysteme RCM RCM bezeichnet die Strategie der Reliability Centered Maintenance (zuverlässigkeitsorientierten Instandhaltung). Hauptansatz der Methodik ist die Anwendung eines Verfahrens, welches es erlaubt, die unter Berücksichtigung mehrerer Kriterien jeweils günstigste bzw. geeignete Instandhaltungsstrategie zu finden. Die Notwendigkeit zur Entwicklung des Verfahrens ergab sich in den 60er Jahren, als die Anbieter im Luftfahrtsektor hohe Sicherheitsziele erreichen wollten bzw. mussten, die regelmäßigen Präventivtauschmaßnahmen aber immens teuer und immer zeitaufwendiger wurden. Das häufig angewendete RCM-II Entscheidungsverfahren nach Moubray 1 basiert vereinfacht gesagt auf der Annahme, dass hierbei die zustandsabhängige Instandhaltung die wirtschaftlichste Strategie zur präventiven Instandhaltung darstellt. Diese sieht nur dann IH-Maßnahmen vor, wenn tatsächliche Anzeichen für einen drohenden Ausfall erkennbar werden und der Ausfall durch die geplante Arbeitsausführung (in der Produktions- bzw. Einsatzpause) die geringsten Kosten des Anlagenstillstandes verursacht. Im Kern also: Tausche ein Bauteil dann, wenn es a) zur Erhaltung der Systemfunktion wirklich notwendig ist und b) möglichst keinen Ertragsausfall durch Anlagenstillstand verursacht. Beobachtbarkeit und Verlauf des fehlerankündigenden Driftprozesses inkl. dessen Streuung. Lebensdauerdaten, die Schlüsse zu Alterungseigenschaften zulassen Kosten bzw. Zeiten für die Zustandsbestimmung und die prophylaktische IH Kosten bei einem Ausfall im Betrieb bekannt sein. 1 Vgl. Moubray, John: RCM II, Reliability-centered Maintenance: Elsevier, Butterworth-Heinemann, 1997 Abschlussbericht EVW Phase

73 Darstellung der Da nicht in jedem Fall eine zustandsabhängige Instandhaltung möglich oder erforderlich ist, versucht die RCM-Methode für diese Fälle eine geeignete Second-Best-Lösung zu finden. Die RCM-Methode wird üblicherweise als moderiertes Verfahren auf Basis von Experteneinschätzungen unter der Betrachtung aller (bekannten) Ausfallmodi (Fehlermodi/mögliche Fehlfunktionen aus der FMEA) und auf Ebene der kleinsten tauschbaren Einheit (KTE) durchgeführt. Sie ist damit ein Verfahren, welches auf einer FME(C)A ausreichender Bearbeitungstiefe aufgesetzt werden kann. Die Auswahlhierarchie für die Instandhaltungsstrategie wird von Moubray als Entscheidungsbaum dargestellt, der vier Grundstrategien für die präventive Instandhaltung einbezieht: Zustandsbedingte IH (als First-Best-Lösung) Geplante Überholung Geplanter Austausch (Präventivtausch) Geplante Fehlersuche (Inspektion zur Ausfallvermeidung) Der operative, ungeplante Tausch nach einem zufälligen Ausfall ist hier nicht primärer Gegenstand der Entscheidung, da sie keine eigene präventive Instandhaltungsstrategie erfordert. Die zu optimierenden Zielgrößen, wie etwa Kostenersparnis oder Anlagenverfügbarkeit, aber auch Anlagensicherheit, Ersatzteilbedarf oder andere weiche Kriterien usw. können je nach Branchenbedingungen und verwendeter Technologie variieren. Das von Moubray vorgeschlagene Entscheidungsverfahren bezieht vor allem: Sicherheits- und Umweltrelevanz Betriebsrelevanz (Anlagenstillstand, Produktionsengpass ) Erkennbarkeit des Alterungs- bzw. Fehlerzustandes in die Wahl der IH-Strategie ein. Hieraus ergibt sich das RCM-Entscheidungsdiagramm: Abbildung 37: RCM-Entscheidungsdiagramm Abschlussbericht EVW Phase

74 Darstellung der Dort, wo nach Durchführung der Analyseschritte keine geeignete Instandhaltungsstrategie für anwendbar befunden wird, sind nach dem Moubray-Ansatz Konstruktionsänderungen entweder notwendig oder wünschenswert. Das aus der Luftfahrt stammende Verfahren wird in der Praxis bei der Aufstellung, häufig aber erst bei der Optimierung des Instandhaltungskonzeptes technischer Anlagen eingesetzt, wobei neuere Lieferverträge bzw. Ausschreibungen auch die RCM-Analyse durch den Hersteller als Bestandteil der Anlagendokumentation zum Nachweis einer ressourcenschonenden Instandhaltungskonzeption (s.a. Abschnitt 2.3.1) für das angebotene Anlagendesign zunehmend fordern. Da (Betrachtung für jedes tauschbare Bauteil + alle Fehlermodi) der Analyseaufwand (mehrere 100 Fehlermodi sind in der Praxis keine Seltenheit) sehr hoch sein kann, dauern die entsprechenden Analysen oft vergleichsweise lange (Monate bzw. Jahre) und lohnen sich damit vor allem dort, wo die durch geeignete präventive Maßnahmen vermiedenen Ausfallkosten oder geminderten Sicherheitsrisiken entsprechend hoch sind. Weitere Erweiterungen des Verfahrens (Einbezug von Kritikalitätsfaktoren oder Begrenzung auf kritische Elemente, Ergänzung um Optimierungsansätze der risikobasierten IH (RBI, FMECA) usw.) werden als Adaption oder Ergänzung oft diskutiert und angewendet. Anders gesagt: RCM ist eine der Optimierungsverfahren, die bei der Aufstellung eines IH-Planes helfen, aber eben nicht alleine den IH-Plan und die zur Umsetzung notwendige Ersatzteilhaltung bestimmen. Den Nutzen seiner Methode sieht Moubray nicht nur in der Minimierung des Aufwandes (bzw. der Erhöhung der Anlagenverfügbarkeit) durch einen systematisch optimierten IH-Plan, sondern auch in einem durch die Moderation erreichten gemeinsamen Funktionsverständnis von Entwicklungsingenieuren und Fachkräften aus dem Bereich der Instandhaltung (s. folgende Abbildung). Abbildung 38: Nutzeneffekte im moderierten RCM-Analyseverfahren nach Moubray Folgende Marktgegebenheiten machen verständlich, warum der Ansatz im Bereich der Windenergie als potenziell nutzbringend eingestuft werden kann, jedoch in der Praxis noch nicht sehr oft angewendet wird. Abschlussbericht EVW Phase

75 Darstellung der Marktbedingung pro RCM kontra RCM Übergang vom Verkäufer zum Käufermarkt X (x) Hoher Analyseaufwand Einsparpotenzial bei baugleichen Anlagen eines Herstellers Einsparpotenzial durch Typenbauweise Wartung derzeit überwiegend beim Hersteller (x) (x) Trend zu Wartungsdienstleistern (x) X Zunehmende Wettbewerbsintensität X (x) Schutz interner Daten (für Hersteller und Dienstleister) kollidiert mit dem Ziel der Markttransparenz Vergleichsweise kleine Kosten des einzelnen Anlagenstillstandes Hohe Kosten der summierten Ausfallzeiten für einen WEA- Typ mit gleicher Anlagenstruktur X X (x) X - Tabelle 3: Einsatzpotenzial der RCM-Analysemethode bei gegenwärtigen Marktbedingungen Die RCM-Analysemethode eignet sich im Bereich der Windenergie vor allem für die Anwendung bei den Herstellern von Windenergieanlagen. Kleinere und herstellerunabhängige Instandhaltungsdienstleister haben von der aufwendigen Methode nur dann einen Nutzen, wenn vertragliche Bestimmungen die Lieferung einer RCM-Analyse durch den Hersteller im Rahmen der Anlagendokumentation fordern. Derartige Forderungen sind vor allem über Ausschreibungen im Markt durchsetzbar, nur begrenzt jedoch über normierte Dokumentationsvorgaben, da eine RCM-Analyse Entscheidungstransparenz schafft. Dies ist aber aus marktstrategischen Gründen nicht immer gern gesehen (s.a. Beispiel zum GSP Abschnitt ). Die RCM-Analyse übernähme bei Ausschreibungen bzw. Lieferverträgen dann zwei Funktionen: 1. Den Nachweis, dass die mitgelieferten Instandhaltungsempfehlungen auf der Basis eines ressourcenoptimierenden und praxisnahen Verfahrens aufgestellt werden, und damit die ggf. ebenfalls gelieferten LCC-Prognosen die Instandhaltbarkeit ausreichend berücksichtigen. 2. Die Lieferung einer fundierten Optimierungsbasis für alle an der Instandhaltung der Anlagen künftig beteiligten Stellen. X X X Abschlussbericht EVW Phase

76 2.3.4 Gefährdungsanalysen Grundlagen Mathematische Modelle Darstellung der Komplexe technische Systeme sind grundsätzlich nicht fehler- oder ausfallfrei. Daher muss ein gewisses Restrisiko gesellschaftlich in Kauf genommen werden, für das es einen vertretbaren Grenzwert festzulegen gilt, der nach Realisierung aller wirksamen Schutzmaßnahmen unterschritten werden muss. Bei Sicherheitskonzepten wird die Verringerung der Wahrscheinlichkeit von Unfällen durch konstruktive Lösungen und ggf. durch zusätzliche Sicherheitssysteme angestrebt. Durch zu spät erkanntes oder unerkanntes Versagen des komplexen technischen Systems oder seiner Sicherheitssysteme ist das Auftreten mindestens einer Gefährdung möglich, aus der dann durch gleichzeitiges Eintreten weiterer ungünstiger Faktoren ein Unfall mit unterschiedlich schweren Folgen resultieren kann. Die mittlere Dauer bis zu einer ersten Gefährdung bzw. der mittlere Abstand zwischen Gefährdungen MTBH (Mean Time Between Hazards) oder die Häufigkeit von Gefährdungen F sind dabei wichtige, praktische Maße für die Gefährdungsfreiheit eines Systems. Das Verhalten eines Systems in Bezug auf das Thema Sicherheit lässt sich mit denselben mathematischen Funktionen beschreiben, wie das generelle Zuverlässigkeitsverhalten. Nur sind bei den Sicherheitsbetrachtungen die relevanten Ereignisse auf solche Vorkommnisse beschränkt, die zu einer negativen Auswirkung auf Personen, Sachverhalte und Umwelt führen können. Die Wahrscheinlichkeit, dass ein technisches System, welches zu einem Zeitpunkt t=0 in Betrieb genommen wurde, bis zum Zeitpunkt t unter definierten Randbedingungen (wie Einsatzumgebung, Wartung, Bedienung, etc.) durchgehend fehlerfrei funktioniert, wird mathematisch in Form der Zuverlässigkeitsfunktion ausgedrückt: Für Sicherheitsbetrachtungen wird zur Unterscheidung von der allgemein gültigen Zuverlässigkeitsfunktion noch der Index H (Hazard) mitgeführt. Der Wert für den mittleren Gefährdungsabstand MTBH lässt sich bei bekannter Zuverlässigkeitsfunktion direkt berechnen: Für die mittlere oder erwartete Häufigkeit von Gefährdungen gilt dann: Die Gefährdungsrate beschreibt dann die bedingte Wahrscheinlichkeit, dass ein bis zum Zeitpunkt t fehlerfrei funktionierendes System innerhalb des nächsten, infinitesimal kleinen Zeitintervalls gefährlich ausfällt: Abschlussbericht EVW Phase

77 Darstellung der Anhand des zeitlichen Verlaufs der Gefährdungsrate lässt sich u.a. abschätzen, inwieweit sich z.b. Alterungs- oder Verschleißeffekte bemerkbar machen (erkennbar durch steigende Gefährdungsraten) Vorgehensweise bei statistischer Datenauswertung Wie die Zuverlässigkeitsprognose erfordert eine begründete Sicherheitsprognose ebenfalls fundierte Eingangsdaten. Nur auf der Basis von Erfahrungen, die wiederum auf der systematischen Analyse von zugrundeliegenden Ereignisdaten aufbauen, sind statistisch abgesicherte Aussagen zum Verhalten des betrachteten technischen Systems in Abhängigkeit seines Lebensdauermerkmals möglich. Die Funktionen zur Beschreibung des Zuverlässigkeits- bzw. Sicherheitsverhaltens werden in der Regel mittels mathematischer Modelle auf der Basis von Stichproben ermittelt. Diese Stichproben enthalten neben relevanten Ereignissen im günstigsten Fall auch Angaben zu sogenannten "Gutläufern", also zu Systemen, die innerhalb einer bestimmten Betrachtungszeit kein relevantes Ereignis aufzuweisen hatten. Diese Informationen sind ebenfalls von entscheidender Bedeutung für die Charakterisierung des Zuverlässigkeits- bzw. Sicherheitsverhaltens, welches sich ohne Berücksichtigung der Gutläuferdaten im Allgemeinen deutlich schlechter darstellen würde, als es der Realität entspricht. Lebensdauerwerte, von denen der Ausfallzeitpunkt nicht bekannt ist, weil er außerhalb des Beobachtungsendes (also rechts davon auf einem imaginär en Zeitstrahl) werden als "Rechtszensierungen" in die mathematischen Lebensdauermodelle zur Ermittlung einer geeigneten Verteilungsfunktion integriert. Zeitabschnitte, für die im Gegensatz zu den Gutläufern bzw. Rechtszensierungen sowohl der Beginn, als auch das Ende von in der Praxis realisierten Lebensdauerwerten vorliegen, werden als vollständige Stichprobenwertebezeichnet. Die rechtszensierten Lebensdauerwerte lassen sich mit Hilfe der sogenannten Kaplan-Meier-Methode 1 bei der Ermittlung des geeigneten Verteilungsmodells berücksichtigen. Die entscheidende Idee dieser Methode ist die, dass die Beobachtungsintervalle für die einzelnen Systeme nicht fest vorgegeben sind, sondern die entsprechenden Zeitintervalle jeweils dadurch festgelegt werden, dass ein (vollständiges) relevantes Ereignis zu verzeichnen ist. Für jedes Zeitintervall wird die bedingte Wahrscheinlichkeit ermittelt, dass das System dieses Zeitintervall fehlerfrei durchläuft, falls es schon bis zum Beginn des neuen Zeitintervalls fehlerfrei funktioniert hat. Die Gesamtwahrscheinlichkeit dafür, einen bestimmten Zeitpunkt fehlerfrei zu durchlaufen, lässt sich dann als Produkt der entsprechenden bedingten Wahrscheinlichkeiten berechnen. Für die Schätzung der relevanten Lebensdauerfunktionen (Zuverlässigkeitsfunktion, Verteilung, Dichte, Ausfallrate) wird in der Regel ein Vertrauensbereich (Konfidenzintervall) angegeben, der den Wertebereich entspricht, in dem aufgrund eines mathematisch-statistischen Schätzverfahrens ein unbekannter Parameter mit einer bestimmten Wahrscheinlichkeit vermutet wird. Das Konfidenzintervall wird durch eine obere und eine untere Konfidenzgrenze beschränkt. 1 KAPLAN EL, MEIER P. NONPARAMETRIC ESTIMATION FROM INCOMPLETE OBSERVATIONS, J AM STAT ASS 1958; 53: Abschlussbericht EVW Phase

78 Spezialfall: keine Ausfalldaten Darstellung der Ein besonderer Anwendungsfall sind Stichproben, die überhaupt keine vollständigen Stichprobenwerte enthalten, sondern sich komplett aus Gutläufern bzw. Rechtszensierungen zusammensetzen. Die üblichen Maximum-Likelihood-Schätzung für zensierte Stichproben liefert für diesen Fall mit = 0 ein wenig hilfreiches Resultat. Es wird vereinfachend angenommen, dass die Lebensdauer der Betrachtungseinheiten einer Exponentialverteilung genügt (konstante, zeitunabhängige Ausfallrate). Dann lässt sich zumindest eine obere Konfidenzgrenze (Grenzwert, den der Parameter mit einer vorgegebenen Sicherheit nicht überschreitet) für angeben. Die Konfidenzgrenze werden mit Hilfe von -Verteilungen berechnet. Mit der ermittelten Verteilungsfunktion wie auch mit den zugehörigen Konfidenzgrenzen ist äußerst vorsichtig umzugehen. Generell gilt, dass eine (parametrische) Verteilungsfunktion nur dann verwendet werden darf, wenn sie empirisch abgesichert ist. Wenn also die Betrachtungseinheiten nur bis zu einer gewissen Zeit T beobachtet worden sind, darf das dadurch gewonnene Ausfallverhalten nicht auf beliebige Zeiten größer als T extrapoliert werden. Und dies gilt unabhängig davon, ob in der Beobachtungszeit relevante Ereignisse zu verzeichnen waren oder nicht, wie im vorliegenden speziellen Anwendungsfall. Die obere Konfidenzgrenze ist hingegen im Beobachtungsbereich gesichert und verwendbar und repräsentiert mit der entsprechenden statistischen Sicherheit eine Mindestzuverlässigkeit bzw. Mindestsicherheit für das betrachtete technische System Konkreter Anwendungsfall Problembeschreibung Die TÜV Rheinland Industrie Service GmbH (TÜV) sollte im Auftrag der ENERTRAG AG (EAG) an einer Untersuchung zur Bewertung des Risikos, welches von zwei von der EAG im Einzugsbereich des Betriebsgeländes der PCK Schwedt Raffinerie GmbH (PCK) geplanten Windenergieanlagen (WEA) des Typs Nordex N117 gamma auf den Betriebsablauf ausgehen kann. Ein erster Entwurf einer quantitativen Risikoanalyse (QRA) wurde vom TÜV im November 2013 vorgelegt. Im Ergebnis eines im Februar 2014 hierzu geführten Arbeitsgesprächs wurde zwischen TÜV und EAG vereinbart, die von den WEA ausgehenden Risiken möglichst realitätsnah auf der Grundlage von Erkenntnissen aus dem tatsächlichen Betriebsverhaltens von WEAs aktueller Bauart abzuleiten. In dem QRA-Entwurf wurde vom TÜV bereits als Fundamentalerkenntnis herausgestellt, dass alle anderen denkbaren Gefährdungsursachen weit hinter dem Fall zurückstehen, in dem von den geplanten WEAs eine abgetrennte Rotorblattsektion in den Betriebsraum des PCK geschleudert würde. Bei allen betrachteten Gefährdungsszenarien geht es ausschließlich um Betriebsabläufe, bei denen Flüssiggas (FG) mittels stationärer FG-Großtanks, Straßentankzüge oder Eisenbahnkesselwagen gelagert, umgeladen oder transportiert wird. Untersuchungsziel war es, die zeitliche Kollisionswahrscheinlichkeit einer WEA-Rotorblattsektion in den einzelnen vom TÜV definierten Schadensszenarien mit statistischen Methoden zu ermitteln. Zielgröße der Berechnung war die jeweilige Kollisionshäufigkeit pro Jahr. Abschlussbericht EVW Phase

79 Analyseverfahren In die Berechnungen zur Ermittlung der Zielgröße gingen folgende Daten ein: Lagebeziehung zwischen den WEA und gefährdeten Objekten Bewegungsmuster gefährdeter Transportmittel in Raum und Zeit Darstellung der Langzeitprognose der richtungsabhängigen Windhäufigkeitsverteilung im Untersuchungsraum zeitliche Wahrscheinlichkeiten für WEA-Rotorblattversagen abgeleitet aus Langzeitbeobachtung von WEA-Realbetrieb Drehzahlcharakteristik von WEA-Rotor abgeleitet aus Langzeitbeobachtung von Realbetrieb typähnlicher WEA Nordex N100 gamma Für die Modellierung der einzelnen Schadensszenarien wurden die Eingangsdaten in einem Geoinformationssystem (GIS) dargestellt und in mehreren Schritten raumanalytisch zu n verarbeitet. Zur Abbildung der denkbaren Spannbreite des Geschehens wurden bestimmte Randbedingungen der Modelle entsprechend variiert, u.a. unter Einbeziehung weiterer Subszenarien. Damit eröffnete sich die Möglichkeit, für die Zielwerte Minima und Maxima berechnen zu können. Die Subszenarien zum Blattversagen stützen sich auf die Beobachtungen des Betriebsverhaltens in WEAs mit großer Vielfalt von vorkommenden Typen und unterschiedlichsten Betriebssituationen. Damit repräsentieren sie lediglich das statistische Durchschnittsverhalten. Bei der Risikobeurteilung des Windenergieprojektes PCK Schwedt ist deshalb weiterhin wertend zu berücksichtigen, welche besonderen Vorkehrungen vom Projektanten und Betreiber getroffen werden, um den Eintritt eines Schadensfalls zu vermeiden. Die Gefahr, im Untersuchungsraum von einer Rotorblattsektion getroffen zu werden, hängt einerseits vom Aufenthaltsort der Person bzw. des Objektes ab (Entfernung zu WEA, bevorzugt auftretende Windrichtungen, etc.). Weiterhin bestimmend ist die Wahrscheinlichkeit, mit der überhaupt mit Rotorblattversagen und Sektionsabwurf gerechnet werden muss. Die räumliche Lage des Einschlagorts einer weggeschleuderten Rotorblattsektion hängt bei Vernachlässigung weiterer Wechselwirkungen mit der Atmosphäre von folgenden Parametern ab: P1 - Entfernung des Masseschwerpunktes der Blattsektion von der Rotormitte P2 - Rotordrehzahl P3 - Winkelstellung der Rotorfläche im Raum P4 - Winkelstellung des Blattes in der Rotorebene Unter Einbeziehung zusätzlichen Voraussetzungen, Betriebscharakteristika und Windgutachten lassen sich diese Parameter näherungsweise berechnen oder simulieren. Als weitere Eingangsgröße zur Berechnung der Kollisionswahrscheinlichkeiten der einzelnen Schadensszenarien galt es, die Häufigkeit eines WEA-Rotorschadens mit Abwurf einer Blattsektion zu ermitteln. Das erfolgte mit zwei umfangreichen Datensammlungen: Betriebsdaten des Unternehmens ENERTRAG Datenbank des vorliegenden EVW-Projektes Weder im EVW-Projekt noch in der von ENERTRAG dokumentierten WEA-Betriebsgeschichte war bis zum Analysezeitpunkt ein Fall dokumentiert, bei dem eine Sektion eines Rotorblatts abgerissen und in die Standortumgebung geschleudert worden ist. Deshalb kam für die Analyse der Daten die Methode der Gutläuferanalyse zur Anwendung. Darüber hinaus wurde zusätzlich noch jeweils die Auswirkung eines fiktiven Rotorblattbruchs nach 1, nach 4 und nach 18 Jahren Betriebszeit auf das Wahrscheinlichkeitsverhalten untersucht (siehe 4.1 Gefährdungsanalyse - Gutläuferuntersuchungen). Abschlussbericht EVW Phase

80 Schlussfolgerungen Darstellung der Je nach zugrunde gelegter Datenbasis ergeben sich zwei ähnliche Ausfallraten bzw. Eintrittswahrscheinlichkeiten für das Ereignis Rotorblattbruch mit Teilabriss: Datenbasis EVW-Daten ENERTRAG-Daten Ausfallrate 1,97 fit 6,00 fit Ereigniswahrscheinlichkeit 1,73E-05 pro Jahr und WEA 5,26E-05 pro Jahr und WEA Tabelle 4: Zusammengefasste der Gutläuferanalyse Folgende weitere Bearbeitungsschritte führten ausgehend von den räumlichen Einschlagdichten zum Rasterdatensatz des Geoinformationssystems für die Gefährdungswahrscheinlichkeit (unter Berücksichtigung der flächenhaften Darstellung der Aufenthaltsorte der gefährdeten Objekte mit ihren jeweiligen zeitlichen Aufenthaltswahrscheinlichkeiten): Normierung der Rasterwerte der räumlichen Einschlagdichte auf den Summenwert 2 (da 2 WEA geplant) Multiplikation der normierten Einschlagdichten mit den zeitlichen Ausfallwahrscheinlichkeiten Abbildung 39: Simulation möglicher Einschläge abgelöster Rotorblatteile (Quelle: ENERTRAG AG, Dauerthal) Letztlich konnte aus den n von Datenanalyse und Simulation abgeleitet werden, dass die Eintrittswahrscheinlichten für die definierten Schadenszenarien deutlich unterhalb eines kritischen Grenzwertes liegen und die verbleibenden Restrisiken als vertretbar akzeptiert werden können. Abschlussbericht EVW Phase

81 2.3.5 Wissensdatenbank Darstellung der Ein branchenunabhängiges Problem der praktischen Analysetätigkeit ist es, dass Analyseergebnisse nicht systematisch historisiert und aufbereitet werden. Dadurch sind bereits bekannte Erkenntnisse oftmals nicht für andere verfügbar. Bei neuen Analyseaufgaben werden so bereits durchgeführte Untersuchungen nochmals angestoßen, weil keine zentrale Wissensbasis verfügbar ist. Auch wenn Experten abwandern, geht sehr viel Praxiswissen verloren. Der im Projekt verfolgte Ansatz einer zentralen Wissensdatenbank in Form einer Kennwertebibliothek (KWB) kann dazu beitragen, den Wissensverlust zu reduzieren und redundante bzw. wiederholende Analysen zu vermeiden. Eine KWB sollte direkt mit dem Analyseprozess und den dabei verwendeten Softwarewerkzeugen verknüpft werden. Diesen integrierten Ansatz verfolgt die IZP seit einigen Jahren. Der Workflow der Analysesoftware RAMS-Office NG verdeutlicht die grundlegenden Zusammenhänge. Abbildung 40: Workflow RAMS-Office NG Auf Basis der vorhandenen Software wurde im Projekt eine spezielle Wissensdatenbank für Windenergieanlagen erstellt. In der Wissensdatenbank können alle Analyseergebnisse wahlweise in anonymisierter Form oder mit den konkreten Bezeichnungen der Analgentypen, Hersteller bzw. Datenlieferanten abgerufen werden. Die Darstellung und Suche von Einträgen erfolgt eine Baumstruktur. Die konkreten Kennwerte können in Tabellenform oder in Einzelsatzansicht eingesehen werden. Darüber hinaus sind auch Lebensdauergrafiken direkt in der Wissensdatenbank abgelegt. Intelligente Suchfunktionen unterstützen die Orientierung und Filterung in der KWB. Neben der direkten Kopplung mit dem Analyseprozess können auch zusätzliche Kennwerte, Beschreibungen oder Kommentare manuelle erfasst werden. Abschlussbericht EVW Phase

82 Darstellung der Abbildung 41:Baumstruktur der EVWII-Wissensdatenbank (Kennwertebibliothek = KWB) Abbildung 42: Einzelsatzansicht in der KWB Abschlussbericht EVW Phase

83 Darstellung der Abbildung 43: Darstellung der Lebensdauergrafiken in der KWB Der besondere Nutzeffekt der als Prototyp erstellten Wissensdatenbank ist die direkte Kopplung mit weiteren Analysemethoden. So ist es möglich, die hier abgelegten Kennwerte u.a. für dies Aufgabenstellungen zu nutzen: Fehlerbaumanalysen LCC-Betrachtungen Ersatzteilplanung Optimierung von Instandhaltungsstrategien und Instandhaltungsintervallen Auch für das angestrebte Förderprojekt WEA.WInD-Pool wird diese Wissensdatenbank ein wesentlicher Erfolgsfaktor sein. Für die breite praxisorientierte Nutzung der KWB ist es jedoch notwendig, die statistische Basis und die Datenqualität der zu Grunde liegenden Primärdaten weiter zu verbessern. Wenn es gelingt, eine statistisch relevante Datengrundlage durch die Einbeziehung weiterer Datenlieferanten zu schaffen, wird die WInD-Pool Wissensdatenbank vielfältige Anwendungsmöglichkeiten bieten: 1. Statistisch abgesicherte Aussagen zu: a. Schwachstellen, Kostentreibern b. Sicherheitsniveau und Risiken c. Zuverlässigkeitsangaben 2. Anonymisierte Vergleiche zu a. Herstellerkonzepten b. Betriebsführungskonzepten c. Instandhaltungsstrategien d. Standorten Abschlussbericht EVW Phase

84 Darstellung der 3. Bewertung von a. Instandhaltungsqualität b. Komponentenzuverlässigkeit 4. Empfehlungen für: a. Betrieb und Instandhaltung b. Anlagen- und Komponentenauswahl c. Repowering, Außerbetriebnahme Prämissen für die Weiterentwicklung und Betrieb der unternehmensübergreifenden Wissensquelle sind: 1. Unabhängiges Benchmarking 2. Anonymisierte Datenverwendung 3. Repräsentative Datenbasis Das Echo der Branche zeigt die Bereitschaft für die notwendige Bereitstellung der Basisdaten als auch das große Interesse an den Analyseergebnissen. Weitere Interessenten an einer Mitwirkung können sich jederzeit direkt beim Fraunhofer-IWES melden. Abschlussbericht EVW Phase

85 2.3.6 Anforderungen an die Datenbasis aus statistischer Sicht Darstellung der Eingangs des vorangehenden Abschnitts 4.2 wird das Ziel des WInD-Pool benannt, welches darin besteht, Informationen für unternehmerische Entscheidungen bereitzustellen. Hierfür wird eine breite statistische Datenbasis gefordert. Die angesprochenen Informationen werden in Form von Kennwerten oder auch Funktionen bereitgestellt und sollen Auskunft über bestimmte Zuverlässigkeitseigenschaften geben. Dabei interessiert man sich für ganz bestimmte Komponenten oder Systeme, die unter speziellen Einsatzbedingungen betrachtet werden sollen. Die Forderung einer breiten statistischen Datenbasis bezieht sich auf: 1. einen hohen Abdeckungsgrad sowohl der verschiedenen Betrachtungseinheiten als auch der Einsatzbedingungen und eine umfangreiche Datenmenge idealer Weise für jegliche (interessierende) Kombination aus Typ einer Betrachtungseinheit und spezieller Einsatzbedingung in Form 2. einer hohen Anzahl beobachteter Betrachtungseinheiten 3. einer langen Beobachtungsdauer der einzelnen Betrachtungseinheiten nach Möglichkeit bis zu deren Ausfall 4. einer großen Gesamtbeobachtungsdauer. Die folgenden Beispiele zeigen, wie die Aussagekraft der Kenngrößen und der in die Berechnung einfließende Datenumfang voneinander abhängen. Im ersten Beispiel gehen wir von einem tatsächlichen Anteilswert von 0,1 aus und stellen uns die Frage, wie gut wir diesen durch eine Stichprobe vom Umfang 50, 500 bzw schätzen können. Eine praktische Anwendung wäre beispielsweise die Bestimmung der Ausfallwahrscheinlichkeit einer Komponente innerhalb der ersten beiden Betriebsjahre. Die folgende Abbildung zeigt, dass man bei einem Stichprobenumfang von 50 mit Schätzwerten im Bereich 0 bis 0,2 rechnen muss. Erhöht man den Stichprobenumfang auf 500, so kann man mit hoher Sicherheit den Schätzwert zwischen 0,06 und 0,14 erwarten. Bei weiterer Erhöhung des Stichprobenumfanges auf 5000 ließe sich der Bereich weiter einengen auf 0,08 bis 0,12. Abbildung 44: Einfluss des Stichprobenumfangs auf die Schätzung eines Anteilswertes Abschlussbericht EVW Phase

86 Darstellung der Das zweite Beispiel demonstriert, wie sowohl der Stichprobenumfang als auch die Beobachtungsdauer Einfluss auf die Schätzung der Lebensdauerverteilung haben. Wieder sei das tatsächliche Ausfallverhalten bekannt. Die Lebensdauer möge weibullverteilt sein mit dem Steigungsparameter = 2 und der charakteristischen Lebensdauer T = 100. Den Verlauf zeigt die schwarze Kurve in dem folgenden Diagramm. Ebenfalls eingezeichnet sind die Schätzungen der Verteilungsfunktion für die Stichprobenumfänge 20, 200 und Um auch den Einfluss der Beobachtungsdauer deutlich zu machen, wurden in die simulierten Stichproben rechtszensierte Daten einbezogen. Die Stichprobe vom Umfang 20 enthält 3 beobachtete Lebensdauern und 17 Rechtzensierungen. Die empirische Verteilung mit den drei resultierenden Sprüngen kann den tatsächlichen Verlauf der Verteilungsfunktion nicht/ kaum widerspiegeln. Zudem erreicht sie nur einen maximalen Ausfallanteil von ca. 65%, da der letzte Lebensdauerwert infolge der kurzen Beobachtungsdauer bei ca. 80 registriert wurde und ein großer Anteil der Rechtszensierungen eine Mindestlebensdauer von über 80 ausweist. Wesentlich besser sieht die Situation bei dem Stichprobenumfang 200 aus. Abgesehen vom Lebensdauerbereich 40 bis 80 und ab 165 aufwärts ist die Anpassung durchaus gut. Wie zu erwarten erhält man die beste Schätzung bei dem Stichprobenumfang Der punktweise Abstand der empirischen Verteilung zur tatsächlichen Verteilungsfunktion ist über dem gesamten Lebensdauerbereich sehr klein. Für die gute Anpassung bis an Verteilungswerte um 1 heran ist die ausreichend lange Beobachtungsdauer ausschlaggebend. Natürlich befördert ein hoher Stichprobenumfang auch lange Beobachtungsdauern. Abbildung 45: Einfluss des Stichprobenumfangs auf die Schätzung einer Verteilungsfunktion Das dritte Beispiel illustriert die Schätzung einer Fehlerhäufigkeit unter der Annahme, dass die Ausfallneigung einer Betrachtungseinheit nicht von deren Alter abhängt. Obwohl diese Annahme sehr einschränkend (konstante Ausfallrate) ist, wird sie sehr häufig angewendet insbesondere dann, wenn man ohnehin keine über eine Mittelwertbetrachtung hinausgehende Lebensdaueraussage treffen kann. Die Annahme kann für den Lebensdauerbereich akzeptiert werden, in dem noch keine Alterung eintritt. Mit dieser Annahme lässt sich feststellen, dass lange Beobachtungsdauern dadurch kompensiert werden können, dass man viele Betrachtungseinheiten beobachtet. Abschlussbericht EVW Phase

87 Darstellung der Entscheidend für die Schätzgüte der Fehlerhäufigkeit ist die Gesamttestdauer (TTT = total time on test), die sich aus der Summe der Beobachtungsdauern aller Betrachtungseinheiten ergibt. Für das Beispiel wurde eine Ausfallhäufigkeit von pro Betriebsstunde vorgegeben. Für drei verschiedene Gesamttestdauern wurden die Verteilungen der möglichen beobachteten Fehlerhäufigkeiten berechnet. Das Bild ähnelt dem Diagramm aus dem ersten Beispiel. Bei einer Gesamttestdauer von 1 Million Betriebsstunden muss man mit Schätzungen d -6 pro Betriebsstunde rechnen. Die Verlängerung der Gesamttestdauer auf 10 Millionen Betriebsstunden engt diesen Bereich auf 1, bis 4, pro Betriebsstunde ein. Schließlich erhält man bei einer Gesamttestdauer von 100 Millionen Stunden einen nochmals verkleinerten Bereich wahrscheinlicher Schätzungen zwischen 2, und 3, pro Betriebsstunde. Abbildung 46: Einfluss der Gesamttestdauer auf die Schätzung einer Fehlerhäufigkeit Das Fazit aus den drei Beispielen lautet: Will man gleichzeitig verlässliche und genaue Kennzahlen liefern, so muss man für eine entsprechende Datengrundlage sorgen. Was angemessen ist, muss im Zusammenhang mit der weiteren Nutzung der Kennzahlen entschieden werden. Abschlussbericht EVW Phase

88 2.3.7 Beispielanalysen Darstellung der Die nachfolgenden Beispielanalysen sollen den Umfang und die wesentlichen Innerhalte der innerhalb des Projektes durchgeführten Analysen verdeutlichen. Zugleich werden weitere Möglichkeiten aufgezeigt, die zukünftig erschlossen werden können, wenn das notwendige Datenfundament errichtet bzw. erweitert wurden ist. Alle Analyseergebnisse wurden anonymisiert, da die Praxisrelevanz der Aussagen durch mitunter geringe Stichprobenumfänge teilweise noch eingeschränkt ist. Auch die Anonymität der Datenlieferanten und Anlagenhersteller muss an dieser Stelle gewährleistet werden. Auf Anfrage kann durch das Projektteam geprüft werden, ob und unter welchen Bedingungen konkrete Fragestellungen auf Basis der vorhandenen Datenlage beantwortet werden können. Es ist geplant, solche Anfragen zukünftig als vermarktungsfähige Dienstleistungen anzubieten. Datenlieferanten erhalten Vorzugskonditionen für Spezialanalysen sowie einen kostenlosen regelmäßigen Standardreport. Die nachfolgende Abbildung gibt einen Überblick zu den grundlegenden RAMS/LCC- Analysemethoden. Bei der Darstellung von Beispielanalysen steht die die RAM-Analyse im FOKUS. Abbildung 47: Überblick zu ausgewählten RAMS/LCC-Methoden ABC-Analysen Über ABC-Analysen, die oft auch als Pareto-Analysen bezeichnet werden, können Schwerpunktprobleme mit einfachen Methoden erkannt werden. Es geht dabei darum, die sogenannten A-Probleme zu ermitteln, die aus verschiedener Sicht (Kosten, Sicherheit, Verfügbarkeit ) den größten Einfluss innerhalb eines Produktes oder Prozesses haben. Zu diesen Analysemethoden gehören z.b. Hitlisten oder andere Häufigkeitsbetrachtungen. Auch die OLAP (Online Analytical Processing)-Technologie als Bestandteil der Data-Warehouse-Technologie ist eine solche flexible Methode um Auffälligkeiten zu ermitteln. Ein OLAP ist vergleichbar mit einem mehrdimensionalen Würfel, dessen Seiten (Dimensionen) der Nutzer beliebig verschieben kann und so seine eigene Sicht auf komplexe Daten erzeugen kann. Ähnliche Ansätze werden auch bei der Erstellung von Pivot-Tabellen verfolgt. In dem Würfel können auch Kosten, Arbeitszeiten und beliebige andere Variablen dargestellt werden. Auch zeitliche Bezüge und Entwicklungen können einfach abgeleitet werden. So z.b. wurden im Projekt Untersuchungen zu Abschlussbericht EVW Phase

89 Darstellung der Jahreszeitabhängigkeit von bestimmten Anlagenstörungen durchgeführt. Weitere Untersuchungen bezogen sich auf folgende Fragestellungen: 1. Schwerpunkte der korrektiven Instandhaltung in Folge von Anlagenstörungen 2. Vergleich der Störanfälligkeit verschiedener Anlagenhersteller und Anlagentypen 3. Welche technischen oder standortbezogenen Kriterien haben den größten Einfluss auf das Störungsverhalten der Anlagen und deren Teilsysteme? Für die Beantwortung solcher und ähnlicher Fragestellungen wurden neben der OLAP-Technologie auch die Methoden der Schwachstellenanalyse eingesetzt. Dazu wurden vorhanden Software- Werkzeuge der IZP Dresden angepasst bzw. weiterentwickelt. Leider war es auf Basis der aktuell vorhandenen Eingangsdaten noch nicht möglich diese Praxisfragen zu bearbeiten: 1. Vergleich der Störanfälligkeit verschiedener Komponentenlieferanten 2. Entwicklungsstandbezogene Schwachstellenbetrachtungen 3. Kostenbezogene Bewertung von Störungen Da die eigentliche RAM-Analyse sehr aufwendig sein kann, sollten dieser immer eine ABC-Betrachtung vorgeschaltet werden. In der Regel sind RAM-Analysen zunächst nur für erkannte Primärprobleme bezüglich des Aufwand-/Nutzenverhältnisses sinnvoll. Abbildung 48: OLAP für WInD-Pool Datenbank Abschlussbericht EVW Phase

90 Darstellung der Abbildung 49: Korrektive Instandhaltungsmaßnahmen pro Anlage und Monat mit mehr als 0,5 Tagen Stillstandszeit Abbildung 50: Erzeugungsverluste pro Monat und Anlage durch korrektive Instandhaltungen Abschlussbericht EVW Phase

91 Darstellung der Abbildung 51: Mittlere Ereignisdauer bei korrektiven Instandhaltungen pro Monat Die vorhergehenden Abbildungen wurden erstellt, um saisonale Abhängigkeiten von Störungen und deren Folgen zu verdeutlichen. Abbildung 52: Mittlere Dauer korrektiver Instandhaltungen pro RDS-PP Ebene 3 Die obige Darstellung zeigt die Abhängigkeit der mittleren Dauer von korrektiven Instandhaltungsereignissen in Abhängigkeit der betroffenen Funktion (RDS-PP Ebene 3). Die im Projekt entwickelten Analysewerkzeuge ermöglichen vielfältige ABC-Analysen. So kann auf konkrete Praxisanfragen flexibel reagiert werden. Es liegen dazu bereits einige Anfragen aus verschiedenen Branchenbereichen vor. Abschlussbericht EVW Phase

92 Zuverlässigkeitsanalysen (R=Reliability) Darstellung der Die Basis für fast alle Analysemethoden ist die Bereitstellung von abgesicherten Zuverlässigkeitskennwerten für Systeme, Teilsysteme oder Komponenten. Hier bietet die durch die IZP Dresden entwickelte Software RAMS-Office NG vielfältige Möglichkeiten für die statistische Analyse. Insbesondere durch die Implementierung von 25 verschiedenen Verteilungsfunktionen und eine automatisierte Modellauswahl kann eine bestmögliche Anpassung der mathematischen Methodik an die jeweilige Datenbasis erreicht werden. Die im Projekt durchgeführten Analysen haben gezeigt, dass gerade für Windenergieanlagen die in der Praxis noch häufig verwendete Exponentialverteilung oft keine optimale Modellwahl ist. Bei einer Vielzahl von Einzelkomponenten wird dieser Verteilungstyp beim Anpassungstest sogar abgelehnt. Das Beispiel in der folgenden Abbildung demonstriert, dass die Exponentialverteilung für den Pitchantrieb der Blattverstellung keine akzeptable Anpassung an die empirische Verteilung aufweist. Auch wenn die Erwartungswerte beider Verteilungstypen annähernd gleich sind, wird bei Verwendung der Exponentialverteilung im vorderen Bereich ein ungünstigeres und im hinteren ein besseres Zuverlässigkeitsverhalten als das tatsächlich vorliegende suggeriert. Durch unangepasste Modellwahl können falsche Empfehlungen z.b. für die Instandhaltungsoptimierung abgeleitet werden. Im Rahmen des Projektes wurden umfangreiche vergleichende Zuverlässigkeitsanalysen durchgeführt. Dabei wurden verschiedene Vergleichsbasen gewählt: Anlagenhersteller Anlagenkonzepte Anlagentypen Technische Konzepte Standortkriterien Über solche Analysen sollen im Rahmen des eingereichten Projektes WEA.Wind-Pool zukünftig konkrete Aussagen zu folgenden Fragen erarbeitet werden: Standortgerechte Auswahl von Anlagentypen Optimale Nutzungsdauer von Anlagen und Komponenten Prognose von Lebenszykluskosten Bewertung von Service-Angeboten Benchmark zwischen Unternehmen An dieser Stelle muss noch auf öffentliche Aussagen dazu verzichtet werden, weil die aus statistischer Sicht erforderlichen Anforderungen an die Datenbasis nur teilweise erfüllt sind. Die Beispielergebnisse auf den folgenden Seiten werden deshalb auch nicht näher kommentiert. Sie verdeutlichen aber die Analysemöglichkeiten, die sich aus einem unternehmensübergreifenden Datenpool ergeben. Abschlussbericht EVW Phase

93 Darstellung der Abbildung 53: Verteilungsvergleich Exponential- und Weibullverteilung Abbildung 54: Ausgewählte Zuverlässigkeitskennwerte mit Konfidenzgrenzen (KG) Abschlussbericht EVW Phase

94 Darstellung der Abbildung 55: Verteilungsvergleich korrektive Instandhaltung zwischen Anlagentypen eines Herstellers Die obige Abbildung zeigt das Zuverlässigkeitsverhalten verschiedener Anlagentypen eines Anlagenherstellers. Dabei ist der Anlagentyp mit dem Erwartungswert (EW) von 149 Tagen (mittlerer Abstand zwischen zwei korrektiven Instandhaltungen) der neueste Anlagentyp. Es ist hier ein Lernprozess bei dem ausgewählten Anlagenhersteller erkennbar. Die Anlagentypen werden mit zunehmenden Erfahrungen auch zunehmend zuverlässiger. Abbildung 56: Vergleich der Erwartungswerte für korrektive Instandhaltungsereignisse bei verschiedenen Anlagenherstellern Auch zwischen den Anlagenherstellern gibt es signifikante Unterschiede bezüglich der mittleren Abstände zwischen korrektiven Instandhaltungsereignissen. Die Unterschiede sind aber nicht allein auf die Zuverlässigkeit der Anlagen zurückzuführen. Es kommen auch unterschiedliche Einsatzbedingungen Abschlussbericht EVW Phase

95 Darstellung der oder unterschiedliche Instandhaltungskonzepte als Ursachen in Fragen. Diese Kriterien wurden bei der Beispielauswertung nicht berücksichtigt. Es ist auch problematisch Zuverlässigkeitsanalysen durchzuführen, wenn die Anlagen sich in einem Fullservice-Vertrag befinden. Hier fehlen in der Regel beim Betreiber der Anlagen detaillierte Informationen zu korrektiven Instandhaltungsmaßnahmen. Da der WInD-Pool momentan noch nicht, durch Herstellerdaten gespeist wird, sind hier noch Datenlücken vorhanden, die es gilt im Fortgang der Arbeiten zu füllen. Abbildung 57: Verteilungsvergleich für RDS-PP Ebene 3 Über die RDS-PP Struktur kann die Zuverlässigkeit verschiedener Funktionsbereiche der Anlagen verglichen werden. Das Ergebnis einer solchen Betrachtung zeigt das obige Bild Verfügbarkeitsanalysen (A =Availability) Verfügbarkeitsanalysen sind für die Windbranche von besonderer Bedeutung. Von der Verfügbarkeit der Anlagen hängen direkt die Einnahmen bzw. die Erzeugungsverluste ab. Deshalb werden auch in allen Betriebsführungsunternehmen regelmäßig systematische Analysen zum Thema Verfügbarkeit durchgeführt. Bei der Verfügbarkeitsanalyse ist eine genaue Definition der konkreten Kenngrößen notwendig. Hier gibt es erhebliche Unterschiede zwischen verschiedenen Branchen und Anwendungsfällen. Aber auch innerhalb der Windbranche gibt es verschiedene Sichtweisen. Von besonderer Bedeutung ist im Windsektor die energetische Verfügbarkeit. Im Lexikon zur Windtechnologie ( heißt es dazu: Die energetische Verfügbarkeit bezieht sich im Gegensatz zur zeitlichen Verfügbarkeit nicht auf die Zeit sondern auf den Energieverlust. Ist die energetische Verfügbarkeit geringer als die zeitliche Verfügbarkeit, fanden Stillstände der Anlage bei windstärkeren Zeiten statt. Die Verfügbarkeit wird in Prozent meist für einen Monat oder für ein Jahr angegeben. Die folgende Darstellung zeigt, dass die anderen Branchen dominierende technische Verfügbarkeit nicht automatisch den Energieertrag bestimmt. (Quelle: Abschlussbericht EVW Phase

96 Darstellung der Abbildung 58: Technische Verfügbarkeit und Energieertrag Da es zum Thema energetische Verfügbarkeit schon zahlreiche Veröffentlichungen gibt, soll an dieser Stelle die Technische Verfügbarkeit betrachtet werden. Das Ergebnis einer technischen Verfügbarkeitsanalyse für 4 Hauptfunktionsbereiche eines Anlagentyps zeigt das folgende Bild. Die technische Verfügbarkeit für das betrachtete Teilsystem für den Zeitraum von einem Jahr liegt bei ca. 97%. Wenn man noch alle anderen RDS-PP-Funktionsbereiche hinzuziehen würde, wäre die technische Verfügbarkeit noch erheblich geringer. Um die Vorgaben für die energetische Verfügbarkeit zu erreichen, ist es deshalb dringend notwendig Instandhaltungsmaßnahmen in windarme Zeiträume zu verlagern. Abschlussbericht EVW Phase

97 Darstellung der Abbildung 59: Verfügbarkeitsbetrachtung mittels Fehlerbaumanalyse Abbildung 60: Ausfallwahrscheinlichkeit für Teilsystem Der Wind-Pool bietet effiziente Möglichkeiten zur Analyse und Optimierung der technischen Verfügbarkeit. Dazu wird insbesondere die Fehlerbaummethodik angewendet. In Kombination mit Windprognosen können diese direkt zur Optimierung und dauerhaften Stabilisierung der energetischen Verfügbarkeit beitragen. Abschlussbericht EVW Phase

98 Instandhaltungsanalysen (M = Maintainability) Darstellung der Ziel von Zuverlässigkeits- und Verfügbarkeitsanalysen ist es sehr oft, die vorhandenen Instandhaltungsstrategien zu bewerten und zu optimieren. Mit Hilfe der Methoden der Instandhaltungs- und Erneuerungstheorie lassen sich so auf Basis von belastbaren Zuverlässigkeitsangaben folgende Aufgabenbereiche unterstützen: Planung von Ersatzteilen und Instandhaltungskapazitäten Auswahl von Instandhaltungsstrategien (präventiv oder korrektiv) Optimierung von Instandhaltungs- und Austauschzyklen Bewertung von Serviceangeboten Auswahl von Komponentenlieferanten nicht nur nach dem Preis. In Abweichung der ursprünglichen Zielstellung des Vorhabens mussten Abstriche bei der geplanten Einführung von neuen Instandhaltungsstrategien gemacht werden. Auf Grund nachfolgender nicht zu beeinflussenden Gründe konnten noch keine konkreten Veränderungen im Instandhaltungsprozess der Projektpartner durchgesetzt werden: Fullservice-Verträge lassen kaum Spielraum für die Änderung von Instandhaltungsstrategien Fehlende Informationen zu Instandhaltungskosten und Ausfallfolgekosten führen zu Unsicherheiten bei der Ergebnisbewertung Unzureichende Datendetaillierung; eine Ereignisspezifizierung bis auf Ebene der kleinsten tauschbaren Einheit (KTE) ist aktuell nur mit hohem manuellen Aufwand möglich. Insbesondere die ungenügende Spezifizierung der betroffenen technischen Elemente lässt keine Optimierung bezüglich konkreter Instandhaltungsobjekte zu. Die mit RDS-PP zurzeit durchgeführte Ereignisbeschreibung ist noch sehr grob und hauptsächlich funktional orientiert. Es gibt aber hier Ideen und Ansätze zur Definition von Instandhaltungsobjekten, deren Umsetzbarkeit noch weiter mit der Praxis diskutiert werden müssen. Trotz der genannten Probleme ist es gelungen die theoretischen Grundlagen für die Instandhaltungsoptimierung zu erweitern und punktuell zu testen. Die Akzeptanz und die Erwartungshaltung der Branche zu dieser Thematik sind sehr hoch. Wenn es gelingt, die Anlagenhersteller, Komponentenhersteller und Service-Unternehmen noch besser einzubinden, sollten auch hier zeitnah praxiswirksame Lösungen möglich sein. Im Projektbeirat wurden die genannten Branchenplayer bereits dazu kontaktiert und befragt. Auch wenn es noch teilweise eine zurückhaltende Einstellung gibt, sind positive Signale erkennbar. Die nachfolgenden Beispiele sollen die Potentiale für die Instandhaltungsoptimierung verdeutlichen. konkrete Handlungsempfehlungen sind daraus nicht abzuleiten. Abschlussbericht EVW Phase

99 Darstellung der Abbildung 61: Anzahl korrektive Maßnahmen pro Jahr für 100 Anlagen Abbildung 62: Optimales Instandhaltungsintervall für ausgewähltes Anlagenteilsystem Abschlussbericht EVW Phase

100 2.4 Test- und Demonstrationssystem Darstellung der Wie in Kapitel 1.1 beschrieben ist das Ziel des Test- und Demonstrationssystems (TDS) den Datenfluss in der Instandhaltung von Windenergieanlagen unter Verwendung einer standardisierten Kommunikation nachzubilden, den Einsatz dieser Standards und weiterer neuer Entwicklungen zu testen und die Vorteile einer digitalen Kommunikation insbesondere für die Instandhaltung von WEA herauszustellen. Das TDS besteht im Wesentlichen aus den drei Bausteinen Betriebsüberwachung/Leitwarte, Instandhaltungsplanung und Instandhaltungsteams, was den Bedingungen im Betrieb und der Instandhaltung von WEA entspricht. Jeder Baustein wird durch ein Modul bzw. mehrere alternativ einsetzbare Software-Module abgebildet. Das TDS ist an den in Kapitel 2.2 beschrieben WInD-Pool und die zugehörige Datenanalyse gekoppelt, diese sind aber kein direkter Bestandteil des TDS. Test- und Demonstrationssystem - Simulation des Anlagenbetriebs - Simulation von Störungen - Visualisierung der Betriebsdaten - Darstellung von Informationen zum Instandhaltungsauftrag - Protokollierung der Instandhaltungsarbeiten - Verwendung von RDS-PP, ZEUS und GSP Modul: SCADA-Viewer Windows 7 Android Windows 8 - Darstellung der IH-Historie - Erstellen von Arbeitsaufträgen - Abschluss von Instandhaltungsberichten Modul: CMMS - Import von Stammdaten - Import von Betriebsdaten - Import von Ereignisdaten - Betriebsdatenauswertung (Performance Benchmark) - Ereignisdatenauswertung (Kennwertebibliothek) - Eregebnisbereitstellung Abbildung 63: Aufbau des Test- und Demonstrationssystems Das Konzept des TDS sah ursprünglich vor existierende Softwaresysteme der Projektpartner und dritter Unternehmen zu verknüpfen und ein in verschiedenen Konfigurationen lauffähiges Gesamtsystem bereitzustellen. Aufgrund massiver Verzögerungen bei der Fertigstellung der Branchenstandards RDS-PP, ZEUS und GSP in den nun vorliegenden Revisionen, war die Verfügbarkeit entsprechender Praxissoftware zum Beginn des Projektes nicht abzusehen. Um möglichst frühzeitig ein betriebsbereites TDS zu realisieren, die Entwicklungsversionen von RDS-PP und ZEUS auf ihre Praxistauglichkeit zu testen und neue Ideen zeitnah umsetzen zu können, entschied das Fraunhofer IWES die notwendigen Module als Prototypsoftware selbst zu entwickeln. Eine Tauglichkeit für den realen Einsatz wurde hierbei explizit nicht angestrebt. Abschlussbericht EVW Phase

101 Darstellung der Im Rahmen der Projektlaufzeit wurden auch in den Systemen der Projektpartner Teilfunktionalitäten des TDS umgesetzt, z.b. die Ereignisbewertung bei GEO mittels RDS-PP und ZEUS. Außerdem wurde durch die Firma RECONSERV GmbH & Co KG das Softwarepaket REGAS entwickelt, dass eine Instandhaltungsdatenerfassung auf Basis von RDS-PP, ZEUS und GSP bietet. Beide Entwicklungen werden in diesem Kapitel ebenfalls vorgestellt. Die Simulation der Betriebsführung/Leitwarte wird mit dem Modul SCADA-Viewer umgesetzt, welches Betriebsdaten simuliert, diese ebenfalls visualisiert und die Simulation von Fehlern incl. des Auslösens eines Instandhaltungsauftrags über das Instandhaltungsmanagement ermöglicht. Das Instandhaltungsmanagement wird über das Modul CMMS (Computerized Maintenance Management System) abgebildet, welches das Erstellen und Abschließen von Instandhaltungsaufträgen erlaubt. Die für den Baustein Instandhaltungsteams entwickelten Prototypen zur mobilen Datenerfassung basieren auf unterschiedlichen Hard- und Softwareplattformen. Weitere Details sind den Kapiteln zu entnehmen. Da das TDS zu Demonstrationszwecken als portables System aufgebaut ist, müssen alle Anwendungen auf den lokalen Geräten lauffähig sein und über ein WLAN miteinander kommunizieren können. Der Zugriff auf standortfeste Infrastruktur/Dienste des Fraunhofer IWES oder die zwingende Nutzung einer Internetverbindung ist nicht vorgesehen. Zum besseren Verständnis erfolgt im nachfolgenden Unterkapitel eine vereinfachte Beschreibung des Instandhaltungsprozesses und eines beispielhaften Informationsflusses Instandhaltungsprozess und beispielhafter Informationsfluss Eine wesentliche Anforderung an das Test- und Demonstrationssystem ist es den Informationsfluss und die grundlegenden Tätigkeiten im Instandhaltungsprozess möglichst plausibel abzubilden. Der zugrunde gelegte Instandhaltungsprozess wird nachfolgend zusammenfassend beschrieben. Die Erarbeitung des beschriebenen Prozesses erfolgte größtenteils im Arbeitskreis GSP, eine weitergehende Beschreibung ist daher auch in der TR 7 D3 der FGW enthalten. Die Durchführung einer Instandhaltungsmaßnahme wird hierbei in fünf grundlegende Abschnitte unterteilt: Auftragserstellung (Betreiber/Betriebsführer oder Serviceunternehmen) Die Erstellung des Instandhaltungsauftrags erfolgt je nach Situation (z.b. Standard- Wartungsvertrag oder Full-Service-Wartungsvertag) entweder durch den Betreiber/Betriebsführer oder intern durch das Serviceunternehmen. Im Anschluss wird der Auftrag an das ausführende Unternehmen übergeben. Auftragsplanung (Serviceunternehmen): Der erstellte Auftrag geht beim Auftragnehmer (Serviceunternehmen) in die Auftragsplanung, wird dort um weitere Informationen wie benötigte Messmittel, Arbeitsmittel, Qualifikationen etc. ergänzt und dann in der Ressourcenplanung terminiert. Der Auftraggeber (Betreiber/Betriebsführer) wird nun zur Freigabe über den geplanten Einsatz, Arbeitsinhalte und das vorgesehene Zeitfenster informiert und gibt die geplante Maßnahme frei. Auftragsfreigabe (Betreiber/Betriebsführer): Der Betreiber/Betriebsführer entscheidet, ob die geplante Maßnahme notwendig ist und evtl. Änderungen an Inhalt oder Zeitfenster des Auftrags erforderlich sind. Der Auftragnehmer erhält eine entsprechende Rückmeldung. Auftragsbearbeitung (Servicetechniker): Nachdem der Servicetechniker alle relevanten Informationen (Stammdaten, Zustand, Arbeitsmaterialien usw.) erhalten hat, prüft er/sie vor Ort die Daten, ergänzt ggf. und beginnt mit der Bearbeitung der Auftragspositionen. Falls weitere Arbeitspositionen notwendig sind, die durch den Auftrag nicht abgedeckt sind und vom Servicetechniker nicht in Selbstvornahme angelegt werden können, wird die Serviceleitung informiert und ggf. ein weiterer Arbeitsauftrag erzeugt. Je nach Vertragslage wird dieser direkt durch die Serviceleitung oder durch den entsprechend informierten Auftraggeber angelegt. Abschlussbericht EVW Phase

102 Darstellung der Auftragsabschluss (Betreiber/Betriebsführer & Serviceunternehmen): Der vom Servicetechniker erstellte Arbeitsbericht wird in durch die Serviceleitung geprüft, ggf. ergänzt und kann nun mit den zwischen den Parteien vereinbarten Inhalten an den Auftraggeber weitergegeben werden. Aus Aufwandsgründen bildet das TDS nicht alle Abschnitte des Instandhaltungsprozesses ab sondern vereinfacht den Prozess insbesondere durch die Entscheidung von einem integrierten Unternehmen auszugehen und die verschiedenen Abstimmungsschritte auszuklammern. Hintergrund hierzu sind auch die großen vertragsspezifischen Unterschiede, während der restliche Instandhaltungsprozess weitgehend einheitlich ist. Der im TDS berücksichtigte Informationsfluss zwischen der WEA, der Leitwarte und dem Servicetechniker ist in Abbildung 64 grob skizziert. Während des regulären Anlagenbetriebs übermittelt die WEA Betriebsdaten an den Betriebsführer. Bei einer Störung sendet die WEA eine Fehlermeldung mit allen vorhandenen Informationen an den Betriebs-führer. Im Idealfall löst dieser daraufhin einen neuen Auftrag aus, wodurch dem Servicetechniker alle zu der Störung vorhandenen Informationen übergeben werden. Während der Fehlerbearbeitung bleibt der Betriebsführer über den aktuellen Arbeitsstand informiert. Nach Abschluss der Auftragsbearbeitung geht die WEA wieder in Betrieb. Alle gesammelten Instandhaltungsinformationen werden zur Auswertung in einer Datenbank gespeichert. Abbildung 64: Grobe Darstellung des Informationsflusses im Test- und Demonstrationssystem Modul Leitwarte SCADA-Viewer Der Baustein Betriebsüberwachung/Leitwarte ist durch das Softwaremodul SCADA-Viewer umgesetzt. Entsprechend des Konzepts des TDS sind die Kernaufgaben des SCADA-Viewer die Simulation des Anlagenbetriebs, die Simulation von Störungen und die Visualisierung der Betriebsdaten. In der Praxis erfolgt die Fernüberwachung von WEA mithilfe von Betriebsführungssoftware, welche Betriebsdaten aus der Anlagensteuerung ausliest, diese aufbereitet und für den Mitarbeiter der Leitwarte visualisiert. Um das Demonstrationssystem möglichst realitätsnah zu gestalten orientiert sich der SCADA-Viewer am Aufbau und dem Funktionsumfang in der Praxis eingesetzter Softwarelösungen. Abschlussbericht EVW Phase

103 Darstellung der Funktionsübersicht existierender Softwarelösungen Basis für die glaubwürdige Umsetzung einer SCADA-Software ist die Kenntnis über den üblichen Aufbau und Funktionsumfang der am Markt erhältlichen Produkte. Zu diesem Zweck erfolgte eine Marktrecherche zu existierender SCADA-Software. Informationsquelle für die Marktübersicht sind Webseiten der Softwareanbieter, Produktbroschüren, weiteres öffentlich verfügbares Informationsmaterial sowie die an der Durham University erstellte Studie Survey of Commercially Available SCADA data Analysis Tools for Wind Turbine Health Monitoring. Es konnten insgesamt 34 verschiede Systeme identifiziert werden, die mit der Erfassung und/oder Auswertung von SCADA-Daten in Verbindung stehen. Davon gingen 23 Systeme in die Marktauswertung ein. Die übrigen elf Produkte wurden aufgrund von unzureichendem Informationsmaterial, Ersatz durch ein Nachfolgeprodukt oder geringer Relevanz für die Thematik der Betriebsführung von der weiteren Auswertung ausgeschlossen. Prozentualer Anteil 100,00% 90,00% 80,00% 70,00% 60,00% 50,00% 40,00% 30,00% 20,00% 10,00% 0,00% Abbildung 65: Auswertung der Marktrecherche zu SCADA-Software basierend auf 23 Produkten Die im Abbildung 65 dargestellten der Marktrecherche zeigen, dass es sich bei SCADA- Software für WEA um einen abgegrenzten Markt handelt. Nur bei etwa 20 % der angebotenen Produkte handelt es sich um branchenübergreifende Lösungen. Der Großteil der SCADA-Software ist speziell für den Einsatz in der Windenergiebranche entwickelt. Kernfunktionen sind Datenerfassung, Visualisierung und Auswertung der SCADA-Daten. Weitere wichtige Bestandteile sind die Anlagenvisualisierung/Prozessvisualisierung, die automatisierte Reporterstellung und das Fehlermanagement. Die Einbindung von Daten aus Condition-Monitoring-Systemen (CMS) ist nur in wenigen Produkten zu finden, ebenso wie die Integration des Instandhaltungsmanagements. Als ganzheitliche Lösung für den Betriebsführer können die meisten Produkte daher derzeit nicht eingesetzt werden. In der technischen Umsetzung zeigt sich die Nutzung eines Internetbrowsers zur Darstellung der Benutzeroberfläche als favorisierte Variante. Damit wird die SCADA-Software unabhängiger vom Betriebssystem und dem Aufenthaltsort des Kunden. Abschlussbericht EVW Phase

104 Anforderungsprofil Darstellung der Die Anforderungen an den SCADA-Viewer ergeben sich aus der Konzeption des TDS sowie aus den n der Marktrecherche und können wir folgend zusammengefasst werden. Anforderungen an den SCADA-Viewer aus dem Konzept des TDS: Simulation des Anlagenbetriebs bzw. von Betriebsdaten Simulation von Störungen/Anlagenstillständen Einbindung von RDS-PP und ZEUS Auslösen und Bearbeiten von Störungsmeldungen Bereitstellen einer Benutzeroberfläche und Datenvisualisierung in Anlehnung an Betriebsführungssoftware Lokale Ausführbarkeit auf einem Notebook Kompatibilität zum gesamten TDS Anforderungen an den SCADA-Viewer aus der Marktrecherche: Graphische Benutzeroberfläche inkl. Verortung auf Karten, Anlagenvisualisierung etc.. Visualisierung und Auswertung von Betriebsdaten auf WEA- und Windpark-Ebene Darstellung meteorologischer Daten Integrierte Reporterstellung für das regelmäßige Berichtswesen Modulbeschreibung Die Programmierung des SCADA-Viewers basiert auf der Programmiersprache LabVIEW 2010 von National Instruments. Hintergrund ist, dass sich die graphische Programmierung in LabVIEW für die Entwicklung von Prototypen eignet und sich schnell erste lauffähige erzielen lassen. Darüber hinaus zeichnet sich LabVIEW 2010 durch eine gute Dokumentation und ausgereifte Funktionen zur Darstellung von Messdaten aus, was den Anforderung zur Visualisierung der Betriebsdaten entgegen kommt. Die Simulation des Anlagenbetriebs basiert auf einem vereinheitlichten Satz realer Betriebsdaten, welche u.a. bei der Fehlersimulation nach Bedarf variiert werden. Abbildung 66: Funktionsumfang des SCADA-Viewer und Aufteilung in Nutzeroberfläche und Hintergrundfunktionalitäten Der Nutzer in TDS hat Zugriff auf eine einheitliche Benutzeroberfläche, welche die Informationen mehrerer Submodule zusammenfassend darstellt bzw. die Steuerung dieser erlaubt. Abbildung 67 zeigt die grundlegende Nutzeroberfläche des SCADA-Viewer. Abschnitt 1 zeigt Informationen zum Windpark, Abschlussbericht EVW Phase

105 Darstellung der Abschnitt 2 Daten zur WEA in verschiedenen Darstellungen, Abschnitt 3 Schaltflächen für die Steuerung der Simulation und Abschnitt 3 die einer integrierten Datenplausibilisierung. Abbildung 67: Übersicht der Nutzeroberfläche des SCADA-Viewer Die Datenvisualisierung (siehe Abbildung 68) im SCADA-Viewer umfasst zunächst die Darstellung der meteorologischen Daten und Betriebsdaten in Tabellarischer Form zu jedem Zeitstempel (4) sowie die Visualisierung in einem Verlaufsdiagramm, in welchem die Verschiedenen Messwerte frei miteinander verglichen werden können. Darüber hinaus erfolgt eine ortsbezogene Darstellung ausgewählter Betriebsparameter (2&3) und die Visualisierung der Stammdaten (5&6) u.a. als Karte unter Verwendung von Google Maps. Abbildung 68: Sichten des SCADA-Viewer zu den Daten einer einzelnen WEA Über die reine Visualisierung der Daten hinaus ist auch die Durchführung grundlegender Auswertungen möglich. Basierend auf den durch die Marktübersicht gewonnen Erkenntnissen und den Erfahrungen des IWES im Bereich der Datenauswertung sind folgende Auswertungen (siehe Abbildung 69) umgesetzt: Anlagenleistung (Referenzkennlinien, Betriebskennlinien und Cp-Werte) Ertrag (Jahresdauerlinie und Volllaststunden) Energetische Verfügbarkeit Abschlussbericht EVW Phase

106 Darstellung der Diese und andere Auswertungen sind auch Bestandteil eines Standardreports, der zu jeder Simulierten Betriebsperiode erstellt werden kann. Aufgrund der hohen Verbreitung ist das Zielformat des Reports das Portable Document Format (PDF). Basis bildet ein Word-Dokument, welches direkt aus LabVIEW- Anwendung erstellt und anschließend als PDF gedruckt wird. Die im Report verwendeten Objekte sind Fließtext, Tabellen und als Grafiken eingebundene Diagramme. Wurde der Anlagenbetrieb u.a. durch die Simulation von Fehlern beeinflusst, lassen sich die Auswirkungen sowohl in der Datenauswertung im SCADA-Viewer als auch im erzeugten Report direkt nachvollziehen, beispielsweise durch eine sinkende energetische Verfügbarkeit. Abbildung 69: Präsentation der Datenauswertung im SCADA-Viewer Für die Störungssimulation sind im SCADA-Viewer verschiedene Fehlervorlagen hinterlegt, die sich über ein entsprechendes Menü aufrufen und einer beliebigen WEA zuweisen lassen. Das Fehlerbild wirkt sich direkt auf die Betriebsparameter der WEA aus, ebenso wird eine Störmeldung in der Fehlerübersicht des SCADA-Viewer hinterlegt. Je nach Handlungsvorgabe kann dieser Fehler nun zur Maßnahmenplanung an die Instandhaltungsplanung weitergegeben werden und wird im TDS an das Modul CMMS weitergeleitet Modul Instandhaltungsdatenmanagement CMMS Der Baustein Instandhaltungsmanagement ist durch das Softwaremodul CMMS umgesetzt. Entsprechend des Konzepts des TDS sind die Kernaufgaben das Annehmen von Störmeldungen aus dem Anlagenbetrieb, das Erstellen von Arbeitsaufträgen unter Berücksichtigung der Instandhaltungshistorie, der Versand der Aufträge an ein Instandhaltungsteam sowie die spätere Kontrolle der Instandhaltungsberichte inkl. Auftragsabschluss. Wesentliche Anforderung an das Modul CMMS ist die Verwendung von RDS-PP, ZEUS und GSP in der Fehlerbeschreibung und Kommunikation. Das CMMS lehnt sich in seinem Aufbau ebenfalls an realen Softwareprodukten an, inhaltlich ausschlaggebend ist der Informationsumfang des GSP. Der der Markt für in Instandhaltungsmanagementsoftware in Bezug auf Windenergie in Vergleich zu Betriebsführungssoftware als klein einzuschätzen ist, erfolgte keine umfangreiche Marktrecherche. Das Anforderungsprofil für das Modul CMMS ergibt sich in diesem Falls primär aus den Erkenntnissen durch die Mitarbeit im Arbeitskreis GSP der FGW sowie durch den Austausch mit den Projektpartnern. Abschlussbericht EVW Phase

107 Anforderungsprofil Darstellung der Die Anforderungen an das CMMS ergeben sich aus der Konzeption des TDS sowie aus den Inhalten des GSP und den Erfahrungen der Projektpartner. Anforderungen an das CMMS aus dem Konzept des TDS: Übernahme von Störmeldungen Darstellung von Instandhaltungshistorien Erstellung und Versendung von Instandhaltungsaufträgen Abschluss von Instandhaltungsberichten Verwendung von RDS-PP und ZEUS Im- und Export von GSP-Dateien Lokale Ausführbarkeit auf einem Notebook Weitere Anforderungen an ein CMMS: Darstellung WEA-Stammdaten inkl. Ortsbezug Ressourcenplanung u.a. Personal, Fuhrpark, Sondermaschinen Terminplanung u.a. in Abhängigkeit von Ressourcen und Witterungsbedingungen Auftragsverfolgung zur Nachvollziehbarkeit eines Auftragsstatus Lagerverwaltung bzw. Inventarüberwachung Verwaltung von Qualifikationen Der Übergang zwischen einem Instandhaltungsmanagementsystem und anderem Systemen wie beispielsweise einer Personalmanagementsoftware (Qualifikationen, Urlaub ) oder einer Lagerverwaltungssoftware ist fließend. Das Modul CMMS konzentriert sich daher auf die Anforderungen aus dem Konzept des TDS und berücksichtigt die weiteren benannten Anforderungen nur vereinzelt Modulbeschreibung Das Modul CMMS zur Abbildung der Instandhaltungsplanung bzw. des Instandhaltungsmanagements im TDS ist als Desktopanwendung für den Betrieb auf einem Windows-Notebook konzipiert und mit LabVIEW 2010 umgesetzt. Es handelt sich hierbei im Wesentlichen um die Umsetzung einer Benutzeroberfläche. Alle Daten der Anwendung sind in einer auf demselben Gerät laufenden Datenbank hinterlegt. Als Datenbanksystem wir die Oracle Database Express Edition (XE) in Version 11 verwendet. Die Nutzung alternativer Datenbanksysteme ist ebenso möglich. Die Inhalte und die Struktur des CMMS orientieren sich an den Festlegungen des GSP. Es ist möglich, nahezu alle im GSP beschriebenen Informationsinhalte abzufragen, anzulegen oder zu bearbeiten. Abbildung 70 zeigt einige Ausschnitte der Nutzeroberfläche, die auch einen Einblick in die Struktur des Moduls geben. Die Benutzeroberfläche erlaubt in einer vorgelagerten Auswahl (nicht dargestellt) die Entscheidung ob Stammdaten von WEA und Windparks bearbeitet werden sollen, oder ob die einer WEA zugeordneten Instandhaltungsmaßnahmen geöffnet werden sollen. Aus dieser Übersicht können entweder bestehende Instandhaltungsaufträge oder Instandhaltungsberichte geöffnet, neu angelegt oder aus einem GSP-Dokument importiert werden. Ebenso lassen sich aus den in der Datenbank hinterlegten Informationen GSP-Dokumente erzeugen und auf verschiedenen Wegen weitergeben. Ziele für die der exportierten GSP-Dokumente sind u.a. die mobile Datenerfassung und der WInD-Pool als unternehmensübergreifende Datenbasis. Abschlussbericht EVW Phase

108 Darstellung der Abbildung 70: Benutzeroberfläche des Moduls Instandhaltungsmanagement - CMMS Zu einem geöffneten Instandhaltungsauftrag lassen sich alle zugehörigen Informationen wie Auftragspositionen, Materialien, Zeiten, Kommentare, Transportvorgänge und die Instandhaltungshistorie anzeigen und bearbeiten. In diesem Rahmen lassen sich u.a. auch ZEUS-Zustandsbewertungen in Bezug auf mit RDS-PP referenzierte Auftragspositionen durchführen Mobile Datenerfassung Service Engineer Die Erfassung von Auftragsinformationen durch die Service-Techniker erfolgt in Instandhaltung von Windenergieanlagen zum Teil auf Papierbasis, zum Teil aber auch mit elektronischer Unterstützung. Dabei kommen Geräte vom Notebook bis hin zum PDA zum Einsatz. Somit existieren am Markt bereits diverse Softwarelösungen zur mobilen Erfassung von Serviceinformationen, diese sind jedoch meist direkt an eine Softwarelösung für das Instandhaltungsmanagement gekoppelt und unterstützen die Richtlinien RDS-PP und ZEUS nicht bzw. wären nur mit hohem Aufwand anpassbar. Zur Überprüfung der Umsetzbarkeit von RDS-PP, ZEUS und GSP auf mobilen Endgeräten fiel daher die Entscheidung das TDS durch eine weitere Eigenentwicklung zu ergänzen. Aus Sicht der EVW-Projektbeteiligten kann durch die Einführung einer mobilen Datenerfassung mittels Tablets während der Instandhaltung folgender Nutzen gezogen werden: Gewichts- und Größenersparnis durch Verzicht auf Tastatur und dadurch bessere Tragbarkeit am Körper im Vergleich zu Notebooks. Erhöhung der Datenqualität durch unmittelbare Datenerfassung am Arbeitsplatz und keine nachträgliche Berichtsführung im Servicefahrzeug oder Büro. Zeitersparnis und schnellere Prozesszeiten, da eine manuelle Nachpflegen/Aufbereitung der Servicebericht entfällt. Integration von aufgenommenen Bildern oder Audiodateien zur Illustrierung und Kommentierung der Befunde und Abhilfemaßnahmen. Eine gute Benutzerführung in der Touchoberfläche und die Möglichkeit eine Barcode-Erfassung beschleunigt auch die Informationserfassung auf der WEA. Abschlussbericht EVW Phase

109 Einsatzbedingungen und Anforderungsprofil Darstellung der Bei der Entwicklung einer mobilen Datenerfassung sind die speziellen Einsatzbedingungen während der Instandhaltung von Windenergieanlagen zu berücksichtigen. Zur Beurteilung der Arbeitsbedingungen wurde in Zusammenarbeit mit dem Projektpartner Windstrom/ENERTRAG ein zweitägiges Beobachtungsinterview durchgeführt. Das Vorgehen basiert auf dem DAkkS Usability Leitfaden und wurden an die Instandhaltung von WEA angepasst. Abbildung 71 stellt den Soll-Prozess in der Bearbeitung eines Instandhaltungsauftrags durch Service-Techniker unter Nutzung der mobilen Datenerfassung im Detail dar. Der Prozess wurde aus den n des Beobachtungsinterview abgeleitet. Abbildung 71: Detaildarstellung des Soll-Prozesses für die Durchführung der Instandhaltungsmaßnahmen durch das Service-Personal Arbeitsorte der Service-Techniker sind die Service-Zentrale, das Service-Fahrzeug und die WEA selbst. Abschlussbericht EVW Phase

110 Darstellung der Die widrigsten Bedingungen treten während der Arbeit an und in der WEA ein. Das Arbeitsumfeld ist daher wie folgend zu charakterisieren: WEA werden bevorzugt in großer Entfernung zu Siedlungsflächen errichtet. Der Handyempfang und die mobile Datennutzung ist daher häufig eingeschränkt. Die Arbeit erfolgt häufig in großen Höhen, es existieren nur teilweise Befahranlagen, so dass der Zugang zu den Gondeln der WEA in vielfach nur über Leitern erfolgen kann. Die persönliche Ausrüstung der Service-Techniker wird dabei am Körper getragen. Nur größere/schwerere Komponenten werden im Zweifel per Bordkran gehoben. Die Arbeit findet teilweise unter beengten Bedingungen statt. In neueren WEA ist in der Gondel selbst zwar meist ausreichend Platz, kleiner bzw. ältere WEA bieten jedoch meist nur schlechtere Platzverhältnisse. Hinzu kommt, dass einzelne Abschnitte (z.b. Rotornabe) der WEA nur durch enge Zustiege erreichbar sind. Wichtigster Bestandteil von WEA sind rotierende bzw. gelagerte Systeme. Öle und Schmierfette kommen daher an vielen Stellen zum Einsatz. Durch die Vielzahl an technischen Systemen auf vergleichsweise beengtem Raum ist die Arbeitsumgebung als stoßgefährlich zu charakterisieren. Die Umgebung besteht aus harten Materialien, die beim Herunterfallen von Teilen/Werkzeug nicht dämpfen wirken. Es können große Fallhöhen erreicht werden. Innerhalb der WEA existiert zwar eine Beleuchtung, gleichzeitig ist die WEA nicht bis in den letzten Winkel ausgeleuchtet. Da die Vielzahl der WEA geschlossen ausgeführt sind und meist nur über kleine Dachluken verfügen, ist eine natürliche Beleuchtung praktisch nicht existent. Ein Teil der Arbeiten findet auch außerhalb der WEA statt. Die Service-Techniker und das Equipment sind daher regelmäßig den Witterungsbedingungen ausgesetzt. Aus dem charakterisierten Arbeitsumfeld, den im Beobachtungsinterview durch die Service-Techniker geäußerten Vorschlägen und Festlegungen im Instandhaltungsprozess lassen sich die folgenden generellen Anforderungen an die mobile Datenerfassung ableiten. Zur regelmäßigen Synchronisation der Auftrags- und Berichtsdaten wird eine mobile Datenverbindung (GSM/UMTS) benötigt. Die Arbeit ohne Datenverbindung muss möglich sein. Die mobile Datenerfassung muss daher sowohl online als auch offline funktionsfähig bleiben. Arbeitsberichte werden häufig durch Bildmaterial ergänzt. Fotos sollen direkt in der mobilen Datenerfassung gemacht werden und der entsprechenden Auftragsposition zugeordnet werden können. Es wird daher eine Kamerafunktion mit hoher Lichtstärke/Auflösung benötigt. Auch Audioaufzeichnungen müssen ergänzend angehängt werden können. Es wird eine robuste Hardware benötigt. Die Hardware soll über eine Taschenlampenfunktion verfügen um dunkle Stellen ausleuchten zu können und somit die Taschenlampe als weiteres Equipment zu ersetzen. 1D- und 2D-Barcodes müssen gelesen werden können. Die Lesbarkeit von RFID-Codes ist ein Zusatzfeature. Sowohl Größe als auch Gewicht der Hardware müssen möglichst gering gehalten werden. Die favorisierte Displaydiagonal beträgt 7 Zoll. Handschuhe werden bei der Arbeit häufig getragen. Es ist daher zwischen kapazitiven und resistiven Touchscreens abzuwägen. Abschlussbericht EVW Phase

111 Darstellung der Die Benutzerführung sollte sich an bereits bekannten Konzepten orientieren. Hierbei ist die mittlerweile sehr hohe Verbreitung von Smartphones zu berücksichtigen. Eine gute Integrierbarkeit der mobilen Datenerfassung in bestehende IT-Umgebungen ist erforderlich. Ein weitreichender Zugriff auf die Grundfunktionen des zugrundeliegenden Betriebssystems ist daher notwendig. Abbildung 72: Haptische Anforderungen an eine MDE-Software-Benutzeroberfläche Softwareseitig steht insbesondere die Bedienbarkeit (siehe auch Abbildung 72) der mobilen Datenerfassung im Vordergrund. Hierzu ist eine klare an den benötigten Informationen und dem Instandhaltungsprozess orientierte Softwarestruktur und Nutzerführung notwendig. Der benötigte Informationsumfang leitet sich aus den Definitionen des GSP ab, umfasst je nach Anwendungsfall aber nur einen Auszug der maximal möglichen Informationen. Grundsätzlich sind durch den Service-Techniker im Zusammenhang mit der mobilen Datenerfassung folgende Tätigkeiten durchzuführen und daher in der Softwarelösung zu berücksichtigen: System Login Auftragsinformationen aufrufen und prüfen (GSP) Auftragsdurchführung Auftragsposition bearbeiten und ergänzen Hinzufügen neuer Auftragspositionen Hinzufügen von Bildern, Videos und Kommentaren Komponentenidentifikation nach RDS-PP Beurteilung nach ZEUS Auftragsabschluss Abschicken des Serviceprotokolls (GSP) System Logout Abschlussbericht EVW Phase

112 Verfügbare Hard- und Softwareplattformen Darstellung der Der Markt der für die mobile Datenerfassung geeigneten Hardwarelösungen und damit verbundenen Betriebssysteme hat sich während der Projektlaufzeit schnell fortentwickelt, was sich auch in der Entwicklung mehrerer Prototypen für die Betriebssysteme Windows 7, Windows 8 und Android widerspiegelt. Die Entwicklung lässt sich wie folgend zusammenfassen: Windows-Tablets sind am Markt schon lange erhältlich, waren jedoch lange Zeit wegen ihrer Größe und dem hohen Gewicht für einen Einsatz ungeeignet. Die Einführung des Apple ipad führte erstmals zur weiten Verbreitung von Tablets. Optimiert auf eine Touch-freundliche Bedienung ist die Benutzerfreundlichkeit hoch. Das geschlossene System und das wenig robuste Design machen es für den Instandhaltungsalltag aber eher ungeeignet. Seit Frühjahr 2011 sind 10-Zoll-Tablets auf Basis von Android verfügbar. Sie bieten eine hohe Benutzerfreundlichkeit und ein offenes System. Ab 2012 waren auch erste Geräte mit einer 7- Zoll Bildschirmdiagonalen verfügbar. Das in 2012 erschienene Windows 8 macht die Windows-Plattform auch für Touch- Anwendungen attraktiv. Seit 2014 sind auch Geräte mit einer Bildschirmdiagonalen kleiner 10 Zoll verfügbar. Für die Bewertung der verschiedenen Betriebssysteme und der zugehörigen Hardware sind folgende Fragen ausschlaggebend: Einsteiger- bzw. Benutzerfreundlichkeit Gestaltung und Anpassbarkeit des Systems sowie Zugriff auf Systemfunktionen Komfort der Entwicklerplattform und Größe der Entwicklergemeinschaft Display Größe & Gewicht Konnektivität (z.b. UMTS) sowie Datenerfassungsschnittstellen (Barcode-, QR-, RFID-Reader) Performance Kamera mit Blitzlichtfunktion/Taschenlampe: beinhaltet eine Kamera mit Blitzlichtfunktion. Akkulaufzeit bzw. Nutzungsdauer Nachdem sich die Nutzung eines 10-Zoll-Tablets auf Basis von Windows 7 im Instandhaltungsalltag als eher ungeeignet herausgestellt hat, erfolgte eine Neubewertung der Situation mit folgendem Ergebnis: Apple ios ist hinsichtlich der Haptik, der Ausstattung der verwendeten Geräte (Kamera, GPS ) und der Verfügbarkeit von Zubehör gut geeignet, durch das geschlossene System wird der Datenaustausch erschwert. Gleichzeitig ist eine dauerhafte Unterstützung älterer Gerät nicht gewährleitet. Android ist hinsichtlich der Anpassungsmöglichkeiten und des Datenaustausches flexibler, es existiert eine große Geräteauswahl inkl. Industrietablets. Das Bedienkonzept ist für viele potenzielle Nutzer bereits von ihrem Smartphone bekannt. Microsoft Windows bietet sich aufgrund der guten Integrierbarkeit in eine bestehende IT- Infrastruktur und die großen Anpassungsmöglichkeiten an. Zum Untersuchungszeitpunkt waren jedoch noch keine Geräte mit einer Bildschirmdiagonale kleiner 10 Zoll verfügbar. Für die Entwicklung eines zweiten Prototyps wurde daher ein 7-Zoll-Tablet mit Android-Betriebssystem ausgewählt. Die Projekterfahrung hat gezeigt, dass für zukünftige Entwicklungen die Möglichkeit der Multi-Plattform-Entwicklung zu berücksichtigen ist. Hierzu sind mittlerweile diverse Entwicklungsumgebungen auf dem Markt verfügbar. Abschlussbericht EVW Phase

113 Beispielimplementierung unter Windows 7 Darstellung der Ergebnis der ersten Phase der Prototypentwicklung ist eine Implementierung für Windows 7 und Tablets mit einer Bildschirmdiagonale von 10 Zoll. Wie das Modul SCADA-Viewer, basiert auch dieser Prototyp auf der Entwicklungsumgebung LabView 2010 und ist als erste Testanwendung konzipiert. Der Prototyp erfüllt folgenden Funktionsumfang: Nutzerlogin Automatische Abfrage des Arbeitsvorrats bei Anmeldung Bereitstellung grundlegender Auftragsinformationen (z.b. Stammdaten zu WEA) Automatische Anmeldung an der WEA und Erfassung von Komponenten durch Barcodescanner Bearbeitung und Erfassung von Arbeitspositionen unter Verwendung von RDS-PP und ZEUS Erfassung von Fahrt, und Arbeitszeiten Da GSP zum Entwicklungszeitpunkt nicht verfügbar war, erfolgt die Kommunikation mit dem TDS über eine Netzwerkschnittstelle von LabView. Die nachträgliche Implementierung des GSP wurde verworfen, da zu diesem Zeitpunkt der Projektbearbeitung bereits die Entscheidung für die Entwicklung auf Basis von Android gefallen war. Abbildung 73: Benutzeroberfläche eines unter Windows 7 umgesetzten Prototyps zur mobilen Datenerfassung Folgende Erfahrungen wurden durch Prototypen gesammelt: Das Betriebssystem Windows 7 und die Entwicklungsumgebung LabView 2010 sind für eine Touch-Bedienung nur bedingt geeignet. Tablet-PCs mit einer Bildschirmdiagonale von 10 Zoll und mehr sind für die Arbeit in der teilweise engen Umgebung in einer WEA zu groß und zu schwer. RDS-PP und ZEUS lassen sich unter Verwendung einer Baumstruktur schnell bedienen und können zur Erfassung von Instandhaltungsinformationen verwendet werden. Die Nutzung von ZEUS ist auf ausgewählte Informationsblöcke zu beschränken, ansonsten leidet die Übersichtlichkeit der Anwendung und die Datenerfassung wird zeitaufwendig. Das Einscannen von Barcodes zur Anmeldung an der WEA und zur Erfassung von Komponenten funktioniert, ein 2-Dimensionale Code wie der Datamatrix-Code oder der QR-Code sind jedoch besser geeignet (höhere Fehlertoleranz und Informationsdichte). Abschlussbericht EVW Phase

114 Untersuchungen zur Implementierung unter Windows 8 Darstellung der Das Erscheinen von Windows 8 im Herbst 2013 führte zu einer neuerlichen Untersuchung der Nutzbarkeit einer Software zu mobilen Datenerfassung auf Basis von Windows. Die als Moder UI bezeichnete alternative Oberfläche von Windows 8 ist auf eine Touch-Bedienung ausgelegt und lässt erlaubt die Erstellung Touchoptimierter Windows-Apps, die sich in die neue Oberfläche von Windows integrieren lassen. Abbildung 74: Vergleich von herkömmlicher und Touchoptimierter Oberfläche für einen Tablet-PC (Windows Demonstrator; Auszug aus der ZEUS-Datenerfassung) Die von IZP Dresden durchgeführte Untersuchung zur Entwicklung eines entsprechenden Datenerfassungstools hat die generelle Eignung von Windows 8 Tablets für die Datenerfassung bestätigt. Da zum Untersuchungszeitpunkt jedoch keine Tablets mit einer Bildschirmdiagonalen kleiner 10 Zoll auf Basis von Windows verfügbar waren und eine Verfügbarkeit auch nicht absehbar war, wurde Windows 8 als Zielsystem verworfen und Android als Zielplattform für die weitere Entwicklung definiert. Da bis zum Zeitpunkt der Berichtserstellung (Frühjahr 2015) diverse Windows-Tablets mit einer Bildschirmdiagonalen kleiner 10 Zoll auf dem Markt erhältlich sind, sollte Windows 8 bzw. das zukünftig erscheinende Windows 10 zukünftig wieder als Einsatzplattform Berücksichtigung finden. Die Verwendbarkeit herkömmlicher Windows-Betriebssysteme bietet den Vorteil einer meist einfachen Integration in die IT-Landschaft der Unternehmen Beispielimplementierung unter Android Im Rahmen einer Masterarbeit wurde am Fraunhofer IWES ein weiterer Prototyp für die mobile Datenerfassung entwickelt, welcher auf dem Betriebssystem Android basiert und sich auf eine Touchoptimierte Bedienung konzentriert. Zielsystem der entwickelten App sind Tablets mit einer Bildschirmdiagonale von 7 Zoll und Android in der Version 4.2. Grundlage für die Entwicklung bilden die in und beschrieben Erfahrungen. Der dargestellte und bearbeitbare Informationsumfang orientiert sind eng an den Inhalten des GSP. Abschlussbericht EVW Phase

115 Folgende Funktionen wurden in diesem Prototyp umgesetzt: Nutzerlogin Import, Export und Versenden von GSP-Dateien Darstellung der Anzeige von Instandhaltungsaufträgen (Stammdaten, Auftragspositionen, Tätigkeiten ) entsprechend der Struktur des GSP Erfassen von Instandhaltungsdaten unter Verwendung von RDS-PP und ZEUS Vollständige Touch-Bedienung Abbildung 75: Ansichten der Benutzeroberfläche zur mobilen Datenerfassung unter Android Folgende Funktionen werden für den Praxiseinsatz als sinnvoll erachten, wurden in diesem Prototyp allerdings nicht umgesetzt: Ansteuerung einer App zum Scannen von Barcodes und QR-Codes zur Anmeldung an der WEA und zur Erfassung von Komponenten. Aufnehmen von Bild- (Kamera) und Audiodateien (Mikrofon) und direkte Zuordnung zu einzelnen Auftragspositionen. Ansteuerung des LED-Blitzes des Tablets direkt aus der App zur Verwendung des Tablets als Taschenlampe. Weiterhin empfehlenswert ist die Integration des Fahrzeuginventars, der Terminplanung und einer Knowledge-Base, welche den Zugriff auf Instandhaltungs-Handbücher zulässt und den Austausch zwischen den Servicetechniker erlaubt (Diskussionsforum). Auch nach Beendigung des EVW-Projektes soll der Android-Prototyp weiterentwickelt werden. In Zusammenarbeit mit dem Fachbereich Informatik der Uni Leipzig soll die App in einer weiteren studentischen Arbeit verbessert und in ihrem Funktionsumfang erweitert werden. Der Quellcode wird zukünftig auch unter verfügbar sein. Abschlussbericht EVW Phase

116 Zusammenfassung Darstellung der Die Erfahrungen zur mobilen Datenerfassung im Rahmen des TDS zeigen, dass mobile Endgeräte gegenüber herkömmlichen Notebooks vor allem dort Vorteile haben, wo anstelle einer Texteingabe vordefinierte Informationskategorien über einen Touchscreen ausgewählt werden können. Die Kodierungssysteme RDS-PP und ZEUS bilden daher eine wichtige Grundlage. Die mobile Datenerfassung über Tablets kann ihre Vorteile vor allem dort ausspielen, wo sie außerdem auch die Möglichkeiten der automatischen Standorterkennung (GPS) und der Objektkennzeichnung (Barcode, RFID) nutzt. Zum Zeitpunkt der Analyse (2013) erschien trotz des erkennbaren Trends zu Tablets keines der am Markt erhältlichen Tablets als vollumfänglich geeignet zur Erfüllung aller Anforderungen der mobilen Datenerfassung. Durch die schnelle Marktentwicklung kann die verfügbare Hardware im Jahr 2015 als zufriedenstellend eingeschätzt werden. Softwareseitig sind Geräte auf Basis von Android und Windows weiterhin als grundlegend geeignet einzustufen. Für weitere Entwicklungen ist die leichte Adaption der Apps bei einer Verwendung von Cross-Plattform fähigen Entwicklungsumgebungen zu berücksichtigen um eine möglichst große Zielgruppe zu erreichen. Eine hohe Datenqualität ist nur dann erreichbar, wenn die Bedienung für den Anwender intuitiv und leicht verständlich ist, und dem Anwender im Bedarfsfall eine leicht zu erreichende interaktive Hilfefunktion angeboten wird. Die hohe Verbreitung von Smartphones kann hier von Vorteil sein, wenn ähnliche Bedienkonzepte angewendet werden. Wegen des hohen Entwicklungsaufwandes unternehmensindividueller Lösungen wird die Entwicklung von Standard-Apps und deren Vermarktung über die jeweiligen App-Stores als sinnvoll erachtet. Dies führt auf Nutzerseite zu deutlich geringeren Kosten und senkt so die Hürde zur Umstellung der Datenerfassung. Voraussetzung hierzu ist die Verwendung der existierenden Richtlinien und Standards. Mit dem Globalen Serviceprotokoll (GSP vgl. Abschnitt 2.1.3) liegt dafür nunmehr eine universell verwendbare Lösung zum Datenaustausch vor. Mittlerweile werden am Markt erste Lösungen angeboten, die mehrere Plattformen für mobile Endgeräte und damit auch Tablets unterstützen. Ein Beispiel ist die Software REGAS Mobil (siehe Kapitel 2.4.5), welche die Systeme Android, Windows 8 und ios gleichermaßen unterstützt und die Standards RDS-PP, ZEUS und GSP einsetzt. Abschlussbericht EVW Phase

117 2.4.5 Industrieimplementierung REGAS Darstellung der Im Rahmen des EVW-Projektes hat das Projektteam bei verschiedenen Anlässen immer wieder Werbung für die Einführung von RDS-PP, ZEUS und GSP gemacht. Während sich RDS-PP nach und nach in der Branche durchsetzt, bedeutet die Einführung aller drei Standards einen größeren Aufwand. Das von der RECONSERV GmbH & Co KG entwickelte Softwarepaket REGAS ( ist eine der ersten Anwendungen, welche diese Standards konsequent umsetzt und für die Arbeit von Betriebsführern, Serviceunternehmen und Sachverständigen nutzbar macht. Zur Unterstützung dieser Entwicklung stand das EVW-Projektteam in regelmäßigem Kontakt mit der RECONSERV GmbH & Co KG und konnte so die Erfahrung aus der Praxisimplementierung im Projekt berücksichtigen. Zwar ist die Software REGAS kein direkter Bestandteil des TDS, kann aber bei Bedarf in dieses integriert werden und soll als erste umfassende Praxislösung nachfolgend kurz vorgestellt werden. Bei REGAS handelt es sich zunächst um eine Browserbasierte-Anwendung zur Erstellung, Ausgabe und Nachbearbeitung von Arbeitsaufträgen, mit besonderem Fokus auf Inspektionen und Wiederkehrende Prüfungen (WKP) an WEA. Darüber hinaus umfasst REGAS eine offlinefähige App für die Betriebssysteme ios, Android und Windows Phone 8, mit denen Daten direkt durch die zuständigen Mitarbeiter an der WEA erfasst werden können. Das Softwarepaket enthält außerdem eine Reporting-Funktion zur Erstellung von Arbeitsberichten. Alle Daten können dem Kunden auch durch einen GSP-Export zur Verfügung gestellt werden. Abbildung 76: Anlagenstruktur nach RDS-PP in REGAS für einen WEA-Typ Abschlussbericht EVW Phase

118 Darstellung der Abbildung 77: Praxisimplementierung REGAS Prüfbausteine einer Konformitätsprüfung inkl. Anwendung von ZEUS Innerhalb von REGAS lassen sich verschiedene WEA-Typen mit den entsprechenden RDS-PP- Strukturen ablegen. Auf der Ebene von einzelnen WEA können Ausrüstungsteile mit ihren Stammdaten (z.b. Hersteller, Seriennummer, ) an die jeweiligen RDS-PP-Funktionen angehängt werden. Die Historie der WEA lässt sich so verfolgen. Für die unterschiedlichen Arbeiten an WEA lassen sich anlagentypübergreifende Prüfumfänge definieren, die sich wiederum auf RDS-PP-Funktionen beziehen. Bei der Anwendung eines Prüfumfangs auf eine konkrete Anlage werden nur diejenigen berücksichtigt, zu denen bei der untersuchten WEA auch die entsprechende RDS-PP Funktionalität existiert. Zu den jeweiligen Prüfungen lassen sich Ergebnisfälle vordefinieren, welche auch eine entsprechende Bewertung nach ZEUS umfassen (s. Abbildung 77). Abschlussbericht EVW Phase

119 2.4.6 Zusammenfassung und Ausblick Darstellung der Zum Projektabschluss stehen verschiedene Module des Test- und Demonstrationssystems zur Verfügung, mit denen sich demonstrieren lässt, wie die Standards RDS-PP, ZEUS und GSP bei der Erfassung von Instandhaltungsdaten eingesetzt werden können. Insbesondere hinsichtlich der mobilen Datenerfassung haben sich die Rahmenbedingungen sehr schnell weiterentwickelt, weshalb verschiedene Module zur mobilen Datenerfassung entwickelt wurden. Da auch die Standards RDS-PP, ZEUS und GSP im Rahmen des Projektes weiterentwickelt wurden, existieren teilweise Kompatibilitätsprobleme. Eine Weiterentwicklung der mobilen Datenerfassung unter Android erfolgt derzeit außerhalb des EVW- Projektes im Rahmen einer studentischen Arbeit an der Universität Leipzig. Das Fraunhofer IWES steht hier auch weiterhin als Ansprechpartner zur Verfügung. Durch die späte finale Verabschiedung der Standards RDS-PP und GSP stand während der Projektlaufzeit keine Praxissoftware zur Integration in das Test- und Demonstrationssystem zur Verfügung. Die Untersuchungsergebnisse des Projektes, beispielweise bezüglich der Anforderungen an die mobile Datenerfassung, können jedoch als Grundlage für die Entwicklung entsprechender Praxissoftware dienen. Die genaue Kenntnis der Instandhaltungsabläufe hat u.a. auch die Richtlinienarbeit des Projektteams unterstützt. Ein Beispiel für die Einführung der beschriebenen Systematik aus RDS-PP, ZEUS und GSP in Praxissoftware ist das Softwarepaket REGAS der Firma RECONSERV GmbH & Co KG. Dieses und andere standardkonforme Softwareprodukte bieten die Chance die Erfassung von Instandhaltungsdaten zukünftig deutlich zu vereinfachen und eine höhere Datenqualität zu erhalten. Zueinander kompatible Standardsoftware verringert gleichzeitig die Kosten für Software und Kommunikation. Abschlussbericht EVW Phase

120 2.5 Praxisimplementierung in den Unternehmen Ziele, aktueller Stand und Potentiale Darstellung der Ziel der anwendungsorientierten Phase 2 des EVW-Projektes war es erste Lösungen direkt bei den Praxispartnern zu implementieren. Darüber hinaus sollten zukünftige Vermarktungspotentiale identifiziert und deren wirtschaftliche Nutzung vorbereitet werden. Die avisierte Implementierung von Projektergebnissen bezog sich auf folgende Bereiche: 1. Umsetzung von Standards zur Datenerfassung 2. Implementierung von Datenschnittstellen 3. Nutzung von Analysemethoden und Werkzeugen bei den Praxispartnern 4. Betriebs- und Instandhaltungsstrategien Die gestellten Ziele konnten im Wesentlichen erreicht werden, wie die folgenden Ausführungen der Praxispartner zeigen. Wie bereits begründet gab es leider Abstriche bei der Implementierung von Betriebs- und Instandhaltungsstrategien. Dafür konnten aber auch neue Felder für die Anwendung der Projektergebnisse erschlossen werden. Dazu zählt vor allem das Thema Gefährdungsanalysen. Hier ist ein spezieller Bedarf z.b. im Rahmen von Standortgenehmigungen vorhanden. Die weiter vorn beschriebene konkrete Risikoanalyse hat einen signifikanten Beitrag zum Fortschritt der Standortgenehmigung für einen neuen Windpark geleistet. Es ist deshalb vom Projektkonsortium geplant ein entsprechendes Dienstleistungsportfolio zu erarbeiten. Der Bedarf der Branche dafür ist vorhanden. Bezüglich der Einführung der Standards für die Datenerfassung hat die bei GEO geschaffene Praxislösung gezeigt, dass die Nutzung von ZEUS mit vertretbarem Aufwand in bestehende Software-Systeme möglich und sinnvoll ist. Für den halbautomatischen Transfer von Betriebs- und Instandhaltungsdaten wurden spezielle Lösungen geschaffen, die bereits beim Aufbau des WInD-Pools erfolgreich genutzt wurden. Über diese Software-Module können anderweitig klassifizierte Daten nachträglich nach ZEUS und RDS-PP gegliedert werden. Dafür wurden entsprechende Zuweisungstabellen bezüglich ZEUS und VGB-EMS erarbeitet. Abbildung 78: Tool zur Zuweisung von ZEUS-Einträgen zu Ereignissen Abschlussbericht EVW Phase

121 Darstellung der Abbildung 79: Weitere Tools zum Datentransfer Neben den allgemeinen Analysen wurden für den Projektpartner ENERTRAG verschiedene Spezialanalysen durchgeführt. Basis dafür waren auch Datenquellen, die momentan noch nicht im WInD-Pool angebunden sind. So konnte nachgewiesen werden, dass die im Projekt verwendete Analysemethodik auch für sensible individuelle Betrachtungen nutzbar ist. Ein solcher Weg kann vermarktungsfähig sein, wenn Interessenten nicht oder noch nicht bereit sind, Ihre Daten direkt in die zentrale Datenbasis einzuspeisen. Vordergründiges Ziel ist es jedoch, alle potentiellen Interessenten von den Vorteilen und der Datensicherheit des Wind-Pools zu überzeugen. Auch wenn es innerhalb des Projektes noch nicht gelungen ist, Einnahmen zu erzielen, wird eingeschätzt, dass innerhalb von 12 Monaten auch erste finanzielle Erfolge für die Projektpartner erzielt werden können, wenn es gelingt, den Betrieb und die Erweiterung der Datenbank sicherzustellen Ein weiteres Geschäftsfeld kann sich im Rahmen der notwendigen Aus- und Weiterbildung des Fachund Führungspersonals ergeben. Dazu wurden bereits erste Absprachen und Bedarfsanalysen mit führenden Bildungsunternehmen wie dem TÜV Nord und der Kraftwerksschule getroffen. Dabei können Erfahrungen zur Nutzung der RAMS/LCC-Technologie aus anderen Branchen auch für den Windmarkt genutzt werden. Abschlussbericht EVW Phase

122 Darstellung der Abbildung 80: Anwenderspezifische OLAP-Analyse Abbildung 81: Anwenderspezifischer Verteilungsvergleich für ausgewählte Teilsysteme Abschlussbericht EVW Phase

123 2.5.2 Implementierung von ZEUS bei GEO Darstellung der Der Zustands-Ereignis-Ursachen-Schlüssel (ZEUS) dient zur Verwaltung von Ereignissen bzw. der standardisierten Beschreibung von Anlagenzuständen, Fehlern und Maßnahmen. Mit Anwendung von ZEUS wird der technische Zustand einer Windenergieanlage über den gesamten Lebenszyklus in einer digitalen Akte festgehalten. Diese Ereignisse werden mit vordefinierten Ereignismöglichkeiten beschrieben. Damit wird es möglich, notwendige Prozesse und Dokumentationen im Bereich der Instandhaltung von Windenergieanlagen einschließlich der dazugehörigen Infrastrukturen zu beschreiben. Die Ereignisse können einem Statuscode in der Statuscodeverwaltung und im Maschinenlogbuch hinzugefügt werden oder statuscodeunabhängig direkt im Modul ZEUS angelegt werden. Außerdem wird damit eine standardisierte Kommunikationsschnittstelle für den Austausch von instandhaltungsrelevanten Daten geschaffen. Um die bei GEO erfassten Betriebsdaten und Meldungen im einheitlichen ZEUS-Format zu erfassen, musste zunächst das hier beschrieben ZEUS-Modul entwickelt und in die WIS- Betriebsführungsdatenbank bei GEO implementiert werden ZEUS in Statuscodes Funktionsweise Im Modul Statuscodes können an jedem Code ZEUS-Informationen angefügt werden, die dann am auftretenden Statuscode im Maschinenlogbuch angezeigt, sowie über diesen Weg automatisch im Modul ZEUS erzeugt werden. ZEUS-Informationen hinzufügen ZEUS-Informationen werden über eine Schaltfläche Bearbeiten, nachdem ein Statuscode markiert wurde, hinzugefügt. In diesem Bearbeitungsfenster kann über ein Tab ZEUS ausgewählt werden. Hier wird die Beschreibung des Ereignisses, Nummer, Code und Bemerkung eintragen. In die Ereignisbeschreibung wird Initial die Statuscodebeschreibung als Vorschlag eingetragen. Über eine Checkbox Statuscode erzeugt ZEUS-Zustand/Ereignis, wird die Eingabemaske aktiviert. Im zweiten Teil des Bearbeitungsfensters wird der Status der Windenergieanlage definiert. Diese Einschätzung erfolgt mit Hilfe vordefinierter Schlüssel für Betriebszustände und können durch eine Drop- Down-Listen ausgewählt werden. Der Status kann in den drei Sichtweisen Betriebszustand, Funktionszustand und Gefährdungszustand beschrieben werden. Bei einigen Schlüsselbeschreibungen sind ergänzende Einträge notwendig, z.b. Schlüssel-Nummer: mit Sollwertvorgabe. Wird diese Schlüsselnummer ausgewählt, werden weitere Eingabefelder aktiv geschaltet. Abschlussbericht EVW Phase

124 Darstellung der Abbildung 82: Hinzufügen von ZEUS-Ereignissen in Statuscodes Nach dem Speichern werden die ZEUS-Informationen an den Statuscode angehängt und werden beim Auftreten dieses Statuscodes in das Maschinenlogbuch mitgegeben. ZEUS-Informationen bearbeiten Bereits erstellte ZEUS-Informationen können jederzeit verändert, bzw. bearbeitet werden. Dafür wird eine Eingabemaske für ZEUS über die Schaltfläche Bearbeiten geöffnet. Hier können in allen Punkten Änderungen vorgenommen werden. Über eine Checkbox Statuscode erzeugt ZEUS-Zustand/Ereignis können Einträge deaktiviert werden. Die ZEUS-Informationen werden dann nicht mehr den auftretenden Statuscodes mitgegeben. Diese Änderungen werden für alle künftig auftretenden Statuscodes verwendet. Die Änderungen wirken sich nicht rückwirkend aus. Wenn an einem Statuscode ZEUS-Informationen gespeichert wurden, können diese Informationen nicht mehr gelöscht werden. Ansicht in der Statuscode-Tabelle In jeder Statuscodeliste gibt es eine Spalte ZEUS. Hier wird ein ZEUS-Symbol an allen Statuscodes angezeigt, in denen bereits ZEUS-Informationen hinterlegt sind. Damit bekommt der Anwender einen guten Überblick, an welchem Statuscode bereits ZEUS-Informationen gespeichert wurden. Wurde ein ZEUS-Eintrag deaktiviert, wird das Symbol grau dargestellt. Abschlussbericht EVW Phase

125 Darstellung der Abbildung 83: Neue Spalte ZEUS in der Statuscodeliste ZEUS im Maschinenlogbuch Funktionsweise In Statuscodes, die im Maschinenlogbuch angezeigt werden, können bereits ZEUS-Informationen hinterlegt sein. Diese Informationen wurden dann über die Statuscode-Konfiguration (im Modul Statuscodes) mitgegeben. Außerdem können direkt im Maschinenlogbuch ZEUS-Informationen hinzugefügt und bearbeitet werden. Diese Informationen werden automatisch im Modul ZEUS angezeigt. ZEUS-Informationen hinzufügen/bearbeiten Je nachdem, ob ein Statuscode bereits ZEUS-Informationen enthält oder nicht, ist die Schaltfläche ZEUS-Zustand/ Ereignis bearbeiten oder ZEUS-Zustand/ Ereignis erstellen auswählbar. Diese Schaltflächen sind in der Symbolleiste, im Menüpunkt Bearbeiten und im Kontextmenü zu finden. Nach Betätigen der Schaltfläche öffnet sich ein modales Fenster in denen Informationen zur Energieanlage, zum Element, sowie Dokumente hinterlegt werden können. Diese drei Punkte sind hier als Tabs angeordnet. Energieanlage Im ersten Tab können, wie schon unter Punkt ZEUS in Statuscodes beschrieben, Informationen zum Ereignis und zum Status der Energieanlage eingetragen werden. Die Angaben zum Park, zur Anlage und der Zeitstempel werden aus dem Statuscodeeintrag mitgegeben und können nicht bearbeitet werden. Elemente In diesem Tab können Elemente, die von diesem ZEUS-Ereignis betroffen sind, angelegt werden. Durch Hinzufügen öffnet sich ein weiteres modales Fenster. Im oberen Teil kann das Element, mit Informationen zur Funktion, Redundanzart und ein Kommentar eingetragen werden. Das Element wird aus einer Drop-Down-Liste ausgewählt. Es werden alle Elemente anzeigt, die im Modul Anlagenstammdaten in der Kategorie Komponenten für diese Anlage hinterlegt sind. Im unteren Teil können Informationen zu den Elementmerkmalen hinterlegt werden. Zu den einzelnen Punkten kann wieder aus fest definierten Schlüsseln mittels Drop-Down-Liste ausgewählt werden. Einige Punkte werden ausgegraut dargestellt und erst wenn ein Schlüssel mit notwendigen Mehrinformationen gewählt wurde, werden diese aktiv geschaltet. Abschlussbericht EVW Phase

126 Darstellung der Abbildung 84: Hinzufügen/Bearbeiten von Elementen eines ZEUS-Ereignisses Dokumente Es können Dokumente einem Zustand bzw. einem Ereignis zugewiesen werden, sowie jedem einzelnen Element. Während ein Element hinzugefügt oder bearbeitet wird, wird in diesem modalen Fenster ein extra Tab Dokumente angezeigt. Dazu können diesem Element Dokumente hinterlegt werden. Im modalen Fenster Zustand/Ereignis bearbeiten können Dokumente für das Ereignis hinterlegt werden. Mit der Schaltfläche Hinzufügen wird ein Auswahlfenster geöffnet, das direkt mit dem Modul Dokumente verbunden ist. Hier kann über ein Filter Dokumententyp, Park, Anlage und Zeitraum eingestellt werden, um in der Dokumentenverwaltung nach dem entsprechenden Dokument zu suchen. Mit der Schaltfläche Übernehmen wird die Verlinkung zwischen der Dokumentenverwaltung und dem ZEUS-Ereignis oder ZEUS Element hergestellt. Wurden notwendige Einträge für ein ZEUS-Ereignis eingegeben, gelangt der Anwender mit Speichern zurück im Maschinenlogbuch. Bearbeitete ZEUS-Informationen werden sofort im Modul ZEUS aktualisiert, neu hinzugefügte ZEUS-Ereignisse werden als neuer Eintrag angezeigt. Abschlussbericht EVW Phase

127 Ansicht in der Maschinenlogbuch-Tabelle Darstellung der Auch hier ist jetzt, wie im Modul Statuscodes, die Spalte ZEUS integriert, in der an allen Statuscodes, an denen ZEUS-Informationen hinterlegt wurden, ein ZEUS-Symbol angezeigt wird. ZEUS-Symbol im Maschinenlogbuch Verwaltung generierter ZEUS-Ereignisse Funktionsweise Das Modul dient zur Verwaltung automatisch generierter und manuell erstellter ZEUS-Ereignisse. Automatisch generierte Ereignisse sind die ZEUS-Informationen, die einem aufgetretenen Statuscode über das Modul Maschinenlogbuch mitgegeben wurden. Diese Informationen können bereits im Modul Statuscodes konfiguriert worden sein. Direkt im Modul ZEUS können Ereignisse manuell angelegt, dupliziert und bestehende Einträge bearbeitet werden. ZEUS-Ereignisse beziehen sich immer auf einzelne Anlagen und können nicht parkübergreifend angelegt werden. Abschlussbericht EVW Phase

128 Tabellenansicht Darstellung der In der Tabelle werden standardmäßig Informationen zu Park, Anlage, Zeitstempel, Ereignisbezeichnung, Betriebszustand, Funktionszustand, Zustandsbewertungszahl, Elemente und Dokumente angezeigt. Über die Funktion Tabelle einrichten, können noch weitere Spalten angezeigt, neu sortiert oder Spalten ausgeblendet werden. Der Inhalt der Tabelle wird über den globalen bzw. lokalen Filter bestimmt. Im lokalen Filter ist die Mehrfachauswahl von Parks und Anlagen für die Ansicht in der Tabelle möglich. Bei automatisch generierten Ereignissen ist die Schaltfläche Zugehörigen Maschinenlogbucheintrag bearbeiten aktiv geschaltet. Diese ist in der Symbolleiste und unter dem Menüpunkt Bearbeiten zu finden. Damit kann direkt der Statuscodeeintrag im Maschinenlogbuch geöffnet und bearbeitet werden. Abbildung 85: Tabellenansicht ZEUS ZEUS-Informationen hinzufügen/bearbeiten ZEUS-Zustände bzw. Ereignisse können über die Schaltfläche Hinzufügen angelegt werden. Über die Schaltfläche Bearbeiten können bereits bestehende Ereignisse verändert werden. Dafür wird zunächst ein Ereignis markiert. Nach Betätigen dieser Schaltflächen öffnet sich ein modales Fenster in dem Informationen in den drei Tabs Energieanlage, Elemente und Dokumente hinterlegt werden können. Dieses modale Fenster wurde bereits unter dem Punkt ZEUS im Maschinenlogbuch beschrieben. Duplizieren Ein bestehender Eintrag kann zur Weiterbearbeitung dupliziert werden. Diese Schaltfläche ist in der Symbolleiste und im Menüpunkt Bearbeiten zu finden. Wird ein automatisch generiertes ZEUS-Ereignis dupliziert, ist das Duplikat nicht mehr mit dem Maschinenlogbucheintrag verbunden. Abschlussbericht EVW Phase

129 Darstellung der Exportfunktion Es werden alle Ereignisse exportiert, die gemäß der Filterfunktion über den globalen oder lokalen Filter in der Liste angezeigt werden. Ereignisse und die zugehörigen Elemente werden jeweils in eine CSV-Datei exportiert. Die aktuellen Filtereinstellungen werden zusätzlich in einer Textdatei exportiert Zusätzliche ZEUS-Informationen Für ZEUS notwendige allgemeine Informationen können in den Modulen Anlagenstammdaten und WEA-Typen hinterlegt werden. Diese Informationen sollen der Nutzung im Zusammenhang mit dem Export der ZEUS-Daten dienen. Anlagenstammdaten Hier wurden in der Rubrik Anlageneinstellungen, in der Kategorie Standort die Punkte Anlagenstandort und Landschaftskategorie hinzugefügt. Für beide Punkte werden fest definierte Auswahlmöglichkeiten angeboten. WEA-Typen In diesem Modul wurden in den einzelnen Typen die Punkte Anlagenkonzept, Lastregelung, Drehzahlverhalten und Generatorbauart hinzugefügt. Auch diese Punkte werden mit vorgegebenen Auswahlmöglichkeiten definiert. Diese Informationen werden nur in diesem Modul gespeichert Fazit Insgesamt kann an dieser Stelle festgehalten werden, dass GEO die Aufgabe Entwicklung einer Datenverarbeitung und -aufbereitung in ein einheitliches Format zur Nutzbarmachung von Onshore- Daten zum Aufbau von Offshore-Fachwissen (ZEUS-Modul) erfolgreich umgesetzt hat. Das ZEUS-System arbeitet fehlerfrei. Als letzte Optimierung ist für die Zukunft ist ein weiterer Automatisierungsgrad hinsichtlich der ZEUS- Datenerfassung geplant, um manuelle Erfassungszeiten noch weiter zu reduzieren. Abschlussbericht EVW Phase

130 2.5.3 WIS-Datenexport zum WInD-Pool bei GEO Beschreibung Windenergie-Informations-System (WIS) Darstellung der Ein wichtiger Aspekt des Projektes war die automatisierte Erfassung und Strukturierung der WEA- Betriebsdaten von den verschiedenen Anlagentypen, welche regelmäßig per Datenfernübertragung von den Anlagensteuerungen ausgelesen werden. Hierfür wurde eine eigens für die Betriebsüberwachung von Windenergieanlagen entwickelte Datenbanksoftware WIS von dem Programmierer SoftEnergy eingesetzt. Das Windenergie-Informations-System WIS ist eine innovative Lösung zur komplexen Auswertung und Überwachung von Betriebs- und Messdaten von Windenergieanlagen. Abbildung 86: Übersicht WIS Systemaufbau Das modular aufgebaute System ist frei skalierbar und erweiterbar, d. h. die Module können auf verschiedene Hardware-Systeme verteilt werden. Hierdurch wird eine optimale Lastverteilung erreicht. Weiterhin ist es möglich, neue Module (z. B. ZEUS-Modul) den Anforderungen entsprechend einzubinden und in die bisherigen Betriebsabläufe zu integrieren. Durch die verwendeten Technologien ist eine nahtlose Einbindung von WIS in SAP- oder NAVISION- Systeme jederzeit möglich. Funktionsbeschreibung WIS steht für Windenergie-Informations-System und stellt ein webbasiertes professionelles Werkzeug für die technische und kaufmännische Betriebsführung von Windenergieanlagen dar. Es nimmt Routine-Aufgaben ab, verwaltet und unterstützt die internen Prozesse, beschleunigt und automatisiert Vorgänge. Abschlussbericht EVW Phase

131 Kommunikation Darstellung der Die Datenholung von den Energieanlagen erfolgt vollautomatisiert durch einen oder mehrere Kommunikationsserver. Die Einrichtung erfolgt entsprechend den Anforderungen und ist frei konfigurierbar. Durch aufwendige Datenanalysen werden speziell angepasste Kommunikationsmodule zur Datenholung bereitgestellt. Hierbei werden alle Hersteller von Windenergieanlagen berücksichtigt. Diese Daten werden in einer Datenbank gespeichert und stehen jederzeit zur Erstellung von Auswertungen, Berichten oder Prognosen zur Verfügung. Weiterhin ist es möglich, vorhandene Lösungen der Datenholung und -speicherung einzubinden. Auswertungen/Berichte Anhand der gewonnenen Daten können Berichte und Auswertungen erzeugt werden, welche frei konfigurierbare Inhalte, wie z.b. Verfügbarkeiten oder Produktion, abbilden. Zusätzlich bietet das WIS spezielle Auswertungen für Investoren, Banken oder Versicherungen. Auch das Erzeugen von Prognosen wurde realisiert und bietet die Möglichkeit, einen Blick in die Zukunft der Anlagen zu werfen. Überwachung Das WIS enthält viele Module, die der automatischen Überwachung von Anlagen dienen. Es kann dabei nicht nur in Übersichtskarten den Status der Windparks oder der Windenergieanlagen darstellen, es enthält auch Module zur automatischen Überwachung von Leistungsparametern wie z. B. Leistungskurven. Werden Auffälligkeiten festgestellt, wird der Betriebsführer per SMS und informiert. Gerade bei der Kommunikation mit analogem Modem passiert es, dass Kommunikationsfehler auf Grund von Modemabstürzen, besetzten Leitungen, usw. auftreten. Das WIS beinhaltet ein Kommunikations-Management-System, dass sich intelligent zu späteren Zeitpunkten erneut einwählt und in der Lage ist, automatisch alle Datenlücken zu finden und diese mit einem Knopfdruck zu schließen. Verwaltung Dank verschiedener Module, die es ermöglichen z. B. Adressen oder Stammdaten der Windparks zentral zu verwalten, lassen sich Prozesse und Entscheidungsfindungen verkürzen, Arbeitseffektivität erhöhen und die Zusammenarbeit und Kommunikation zwischen den Mitarbeitern intensivieren. Analysen Ist der Windpark rentabel? Welche Fehler treten wo am häufigsten auf? Haben sich Optimierungsmaßnahmen positiv auf den Windpark ausgewirkt? In welchem Abstand finden Reparaturmaßnahmen statt? Welche Komponenten verursachen im Vergleich zu Komponenten anderer Anlagentypen Probleme und wie hoch ist der dabei entstandene Ertragsausfall? Diese und weitere Fragen lassen sich mit den Analyse-Modulen des WIS komfortabel beantworten. Das WIS wurde optimal auf die Unternehmensstruktur und Geschäftsprozesse bei GEO abgestimmt und schafft eine gemeinsame Arbeitsplattform für alle Mitarbeiter. Mit dem WIS können alle im Unternehmen anfallenden Informationen gesammelt, verwaltet, ausgetauscht und gezielt verarbeitet werden. Abschlussbericht EVW Phase

132 Darstellung der Die Aufgabe Aufbau einer automatischen Datenerfassung sämtlicher online eingehenden Betriebsund Instandhaltungsdaten aus den unterschiedlichen Anlagensteuerungen in eine einheitliche Betriebsführungsdatenbank (WIS-Datenbank) wurde erfolgreich von GEO umgesetzt. Für die Zukunft hat GEO die Einbindung des GSP (Globales-Service- Protokoll s. Kapitel ) in die hier vorgestellte Datenbank geplant Datenexport zum WInD-Pool Ziel war es, einen Datenexport für die Überführung der Stammdaten, Ereignisdaten und Zustandsdaten aus der GEO-Betriebsführungsdatenbank WIS (ZEUS-Daten) zum zentralen Windenergie-Informations- Daten-Pool (WInD-Pool) zu generieren. Im WInD-Pool, der im Rahmen dieses Projektes geboren wurde, werden WEA-Betriebs- und Ereignisdaten (vorzugsweise im ZEUS-Format) von sämtlichen am WInD-Pool teilnehmenden Betriebsführern und Windenergieanlagenbetreibern gesammelt. Durch diesen gemeinsamen WInD-Pool wird eine ausreichende Datengrundlage geschaffen, um aussagekräftige Analysen aus einer breiten statistischen Basis zu erstellen. Zur bereits vorhandenen CSV-Export-Funktion wurde im ZEUS-Modul der Betriebsführungsdatenbank WIS eine zusätzliche XML-Export-Funktion geschaffen. Über diese Export-Funktion können die Stammdaten, Ereignisdaten und Zustandsdaten von auswählbaren Windenergieanalgen in frei definierbaren Zeiträumen zum WInD-Pool übertragen werden. Der Export ist über die Menüleiste Export Exportieren als XML-Datei zu erreichen. Abbildung 87: Export von Daten aus WIS über XML-Datei Abschlussbericht EVW Phase

133 Darstellung der Struktur des XML-Exportes Stammdaten-Park XML-Bezeichner Beschreibung Kommentar windzone Int Standortklassifikation Windindexzone aus den Parkeinstellungen Index zipcode Int Windparkidentifikation PLZ aus den Parkeinstellungen Standort Pflichtfeld Pflichtfeld Stammdaten-Anlage XML-Bezeichner Beschreibung Kommentar serialnumber Int Anlagenidentifikation Seriennummer aus den Anlageneinstellungen Initialdaten zipcode Int Windparkident PLZ aus den Parkeinstellungen Standort powerplanttype String(10) Anlagentyp Anlagentyp aus den Anlageneinstellungen Initialdaten yearofconstruction Int Inbetriebnahmedatum Baujahr aus den Anlageneinstellungen Initialdaten commissioningdate DataTime Beginn der Datenerfassung Inbetriebnahmedatum WIS aus den Anlageneinstellungen Initialdaten decimmissioningdate DataTime Ende der Datenerfassung (aus der Beobachtung/Ende der Betriebsführung) Außerbetriebnahmedatum WIS aus den Anlageneinstellungen Initialdaten Pflichtfeld Pflichtfeld Pflichtfeld Pflichtfeld Pflichtfeld Pflichtfeld Ereignisdaten XML-Bezeichner Beschreibung Kommentar code String(20) Eindeutiges Ereignis-Ident Statuscodenummer aus dem MLB begin DataTime Störungsbeginn (Ereignisbeginn) Zeitstempel aus ZEUS oder dem MLB end DataTime Ende der Maßnahme Zeitstempel aus dem MLB statusoverview String(20) Fehlernummer und Fehlertext aus Anlagensteuerung Code und Beschreibung aus dem MLB Pflichtfeld Pflichtfeld Pflichtfeld Pflichtfeld Abschlussbericht EVW Phase

134 Darstellung der productioncounter Int Anlagenzähler in kwh Produktionszähler (wenn vorhanden) aus den 10min-Daten zum Zeitpunkt des Störungsbeginns (Angabe in kw) lossofproduction Int Einnahmeverluste in KWH Ertragsausfall aus dem MLB (Angabe in kw) comment String(20) Kommentar / Freitext zum Ereignis component String(20) Betroffene Funktionen/Baugruppen/Kompon enten Bemerkung aus dem MLB Komponente aus MLB referencedesignation String(20) Getauschte Komponenten Referenzkennzeichen aus dem Element operatingstatus String(20) Art des Ereignisses Betriebszustand aus ZEUS (Block 1) dem Primäre Tätigkeit aus ZEUS (Block 2) elementstatus String(20) Ursache des Ereignisses Funktionszustand aus Zeus (Block 2) primaryactivity String(20) Durchgeführte Tätigkeiten faultdiagnosticopportunity String(20) Erkennungsgelegenheit des Fehlers diagnosticsymptom String(20) Primäres Erkennungssymptom needformeasures String(20) Folgen des Ereignisses (betrieblich und technisch) measuretype String(20) Instandhaltungsart (Unterscheidung nach präventiv und korrektiv) Tabelle 5: Stamm- und Ereignisdaten für den Export zu WInD-Pool Erkennungsgelegenheit aus ZEUS (Block 2) Erkennungssymptom aus ZEUS (Block 2) Maßnahmebedarf ZEUS (Block 2) aus Maßnahmeart aus ZEUS (Block 2) Besonders wichtiges Feld Besonders wichtiges Feld Besonders wichtiges Feld Pflichtfeld Besonders wichtiges Feld Pflichtfeld Besonders wichtiges Feld Pflichtfeld Besonders wichtiges Feld Besonders wichtiges Feld Besonders wichtiges Feld Pflichtfeld Fazit und Ausblick Der WInD-Pool bietet der Branche die Chance, zusätzliches Wissen aus dem statistischen Verhalten der Windenergieanlagen zu generieren und in vielen verschiedenen Wertschöpfungsprozessen im Lebenszyklus einer WEA einzusetzen. Der besondere Zweck des gemeinsamen WInD-Pools liegt in der Chance, belegbare Aussagen hinsichtlich WEA-Sicherheit, Zuverlässigkeit, Verfügbarkeit, Instandhaltung und Betriebskosten zu ermitteln. Mit diesen Angaben steht dem Betreiber bzw. Betriebsführer ein Vergleichsmaßstab zur Verfügung, mit dem er die Qualität seiner eigenen Aktivitäten bewerten und evtl. notwendige Veränderungen ableiten kann. Abschlussbericht EVW Phase

135 Darstellung der Als unternehmensübergreifende Brancheninitiative steht der WInD-Pool sowohl zur Ermittlung von Zuverlässigkeitskennwerten als auch als Benchmark-Plattform zur Verfügung. Die Analysen der Daten werden in diesem Projektverbund durch die Projektpartner Fraunhofer IWES und IZP Dresden, welche den WInD-Pool treuhänderisch verwalten, durchgeführt. Mit Umsetzung der hier vorgestellten Datenexport-Funktion hat GEO die Aufgabe Schaffung einer abgestimmte Datenexport-Schnittstelle zur Integration der Betriebs- und Instandhaltungsdaten in eine gemeinsame Datenbankstruktur WInDPool (Datenexport WInD-Pool) erfolgreich umgesetzt. GEO hat sich über eine Kooperationsvereinbarung mit den Projektpartnern bereit erklärt - auch über das Projektende hinausgehend - erfasste Betriebs- und Ereignisdaten über die o. g. Schnittstelle dem gemeinsamen Winddatenpool zur Verfügung zu stellen Implementierung von ZEUS und RDS-PP bei ENERTRAG ZEUS-Implementierung ENERTRAG verwendet die Datenbank PowerSystem für die Betriebsführung. Das PowerSystem wurde im Rahmen von EVW-PHASE 2 um die Verwaltung von ZEUS Inspektionsprotokollen erweitert. Abbildung 88 zeigt das Formular, mit dem Nutzer ZEUS Inspektionsprotokolle vollständig eingeben und bearbeiten können. Abbildung 88: Das Formular für ZEUS Inspektionsprotokolle im PowerSystem Abschlussbericht EVW Phase

136 Darstellung der Jedes ZEUS Inspektionsprotokoll wird im PowerSystem einer Energieanlage zugeordnet, wie Abbildung 89 zeigt. Das ausgewählte Beispiel zeigt ein ZEUS Protokoll für drei Komponenten einer Energieanlage. Abbildung 89: Die Zuordnung von ZEUS Inspektionsprokotollen zu Energieanlagen RDS-PP Implementierung Da das PowerSystem schon seit 15 Jahren ein eigenes Kennzeichnungssystem namens Baugruppenklassifizierung verwendet, war es notwendig, jedem ZEUS-Code eine Baugruppenklassifizierung zuzuordnen. Dieses sogenannte Mapping kann im PowerSystem von editiert werden, wie Abbildung 90 zeigt. Abbildung 90: Das Mapping zwischen RDS-PP und Baugruppenklassifizierung Dank dieses Mappings können in den Berichten und im der Bearbeitung beide Kennzeichnungssystem angezeigt werden, und der Nutzer muss nur eines davon eingeben der zugehörige Code im anderen System wird anhand des Mappings automatisch übersetzt Abschlussbericht EVW Phase

137 Darstellung der Abbildung 91: Die RDS-PP Kennzeichnung wird bei einer Störung unten automatisch angezeigt Fazit und Ausblick Aus Sicht von ENERTRAG hat das Forschungsprojekt mit ZEUS und RDS-PP wertvolle Konzepte erarbeitet, die leider bislang aufgrund des geringen Reifegrads der Windbranche noch wenig Wiederhall finden. Allerdings der für GSP, RDS-PP und ZEUS notwenige Reifeprozess schon im Gange und wurde auch durch das Forschungsprojekt befeuert. Obwohl die Förderdauer des Forschungsprojektes vorbei ist, programmiert ENERTRAG weiter an dessen Zielen und hat auch Konzepte aus dem Forschungsprojekt in die Akkreditierung seiner Betriebsführung aufgenommen, so dass sie auch in den kommenden Jahren gelebt werden Implementierung von GSP bei WindStrom Wie Abschnitt zeigt, beginnt der GSP-Prozess mit einem Arbeitsauftrag an den Instandhalter. Im ENERTRAG PowerSystem wurden für diesen GSP Arbeitsauftrag zwei unterschiedliche Bildschirmformulare programmiert: Eines für Arbeitsaufträge an den hauseigenen ENERTRAG Service, und eines für externe Service Unternehmen. Ersteres wird bei ENERTRAG Auftrag genannt, und letzteres Bestellung. Zwischen beiden Varianten wird unterschieden, weil die Leitwarte bei hauseigenen Aufträgen den Zugang zum ERP-System Navision vom Instandhalter hat, bei externen Bestellungen aber über keinen Zugang zum ERP-System des Instandhalters verfügt. Abbildung 92 zeigt das Formular für externe Bestellungen. Es ist ein Teil-Formular eine Störung einer Energieanlage. Diese externe Bestellung wird in der PowerSystem Datenbank im GSP Format gespeichert und dann an das ERP-System Navision übertragen, denn das Bestellwesen der Betriebsführung läuft über Navision. Die in der PowerSystem Datenbank hinterlegten Informationen zur Störung müssen nicht erneut eingegeben werden, sondern werden automatisch aus den anderen Teil-Formularen übernommen und in GSP gespeichert. Die im Formular angezeigten Namen der Attribute entsprechen den in Navision verwendeten Namen, und nicht der GSP Konvention. Es sind auch zusätzliche Attribute dabei, die in GSP nicht definiert sind, aber in Navision benötigt werden. Da GSP flexibel um zusätzliche Attribute erweitert werden kann, war das hinzufügen dieser Navision- Attribute möglich, ohne den GSP Standard zu verletzen Im Winter 2015/16 werden weitere Formulare für die mobile Erfassung von Inspektionsprotokollen erstellt werden, um die im Forschungsprojekt erarbeitete Konzepte besser zum Tragen zu bringen. Der Abschlussbericht EVW Phase

138 Darstellung der Enertrag Service hat Interesse signalisiert, die mobile Erfassung von Service-Berichten im Jahr 2016 anzugehen. Abbildung 92: Ein GSP Arbeitssauftrag an externe Instandhalter Abbildung 93 zeigt das Teilformular für GSP Arbeitsaufträge an den hauseigenen Instandhalter ENERTRAG Service. Hier werden zusätzliche Navision-Attribute eingetragen und im GSP-Format gespeichert, die nur beim ENERTRAG Service relevant sind, wie etwa Verkäufer-Code, Prioritätskennzeichen oder Problembereich. Abbildung 93: Ein GSP Arbeitsauftrag an den hauseigenen Instandhalter Leider konnte weder der ENERTRAG Service noch externe Instandhalter überzeugt werden, eine Datenschnittstelle zum Empfangen der Arbeitsaufträge im GSP-Format bereitzustellen. Daher werden die Arbeitsaufträge in PDF umgewandelt und per an den Instandhalter verschickt. Die Serviceberichte kommen immer noch auf Papier zurück vom Instandhalter. Der Geschäftsführer eines Instandhalters hat sich strikt einer Übertragung der Serviceberichte im GSP- Format verweigert. Die Begründung für die Entscheidung war, dass ihm eine so präzise Transparenz schadet, weil ein GSP-Bericht eine detaillierte Auswertung ermöglicht, wie hoch seine Marge an dem Auftrag ist. Diese kaufmännische Entscheidung hat verhindert, dass die GSP-Serviceberichte von den Abschlussbericht EVW Phase

139 Darstellung der Monteuren in einem mobilen Endgerät eingegeben werden, wie es im Forschungsprojekt ursprünglich geplant gewesen war. Die Programmierung des PowerSystems ist aber für die Anwendung von GSP im hauseigenen Service und bei externen Dienstleistern vorbereitet. Wenn ein Instandhalter also auf diesen Standard wechselt entweder aufgrund einer freiwilligen Entscheidung oder einer Vereinbarung zur GSP-Anwendung in Serviceverträgen oder Ausschreibungen kann dieser zeitnah zur Anwendung kommen. Die GSP-Daten werden in einer Web-Anwendung verwaltet, die auch auf mobilen Endgeräten funktioniert und daher dem Monteur vor Ort im Windpark zur Verfügung stehen kann. Im Winter 2015/16 werden weitere Formulare für die mobile Erfassung von Inspektionsprotokollen erstellt werden, um die im Forschungsprojekt erarbeitete Konzepte besser zum Tragen zu bringen. Der Enertrag Service hat Interesse signalisiert, die mobile Erfassung von Service-Berichten im Jahr 2016 anzugehen. 2.6 Öffentlichkeitsarbeit/ Wissensverbreitung Als praxisorientiertes Forschungsvorhaben ist das EVW-Projekt auf Feedback aus der Windbranche angewiesen und verfolgt das Ziel, die erarbeiteten Lösungen möglichst frühzeitig in die Anwendung zu überführen. Gleichzeitig lassen sich die Konzepte des EVW-Projekts nur bei entsprechender Verbreitung in der Praxis realisieren. Eine umfassende Öffentlichkeitsarbeit und Wissensverbreitung war daher für den Projekterfolg unerlässlich. Hierzu wurden folgende Aktivitäten durchgeführt: Regelmäßige Durchführung des Projektbeirates und Vorstellung der Projektergebnisse. Gremienarbeit zur Umsetzung und Verbreitung der im Projekt benötigten Standards. Publikationen in Zeitschriften und Büchern. Vorträge bei Messen, Seminaren und Konferenzen. Betrieb und Pflege der Projektwebseite. Zur Unterstützung der Öffentlichkeitsarbeit und Wissensverbreitung wurde die FGW e.v. durch einen Unterauftrag in das Projekt eingebunden und konnte insbesondere durch ihre lange Erfahren in der Gremienarbeit und die vorhandenen Branchenkontakte zum Projekterfolg beitragen Projektbeirat Der bereits im EVW-Projekt Phase 1 installierte Projektbeirat wurde in Phase 2 des Projektes fortgeführt, erweitert und in insgesamt vier Sitzungen über die Fortschritte im Projekt informiert und bzgl. der weiteren Schritte im Projekt befragt. Der Projektbeirat dient damit einerseits dem Ziel die Projektergebnisse einem möglichst großen Anwenderkreis zugänglich zu machen, gleichzeitig übernimmt der Projektarbeit als unterstützendes Gremium die Kontrolle des Projektfortschrittes und der Praktikabilität der entwickelten Konzepte und Lösungen. Alle Unterlagen zu den Sitzungen des Projektbeirats sind unter abrufbar. Nr. Datum Schwerpunktthema Teilnehmerzahl Vorstellung des Projektes EVW-Phase Datenerfassung mittels RDS-PP und ZEUS Praktische Anwendung von ZEUS und GSP Startschuss für den WInD-Pool 20 Tabelle 6: Treffen des Projektbeirats am Standort des Fraunhofer IWES in Kassel Abschlussbericht EVW Phase

140 Darstellung der Der EVW-Projektbeirat setzt sich aus einer Vielzahl renommierter Unternehmen der Windbranche zusammen und repräsentiert die verschiedenen Interessensgruppen (Betreiber/Betriebsführer, Servicedienstleister, Hersteller, Sachverständige, Softwareentwickler). Die Vielzahl der beteiligten Unternehmen zeigt die hohe Relevanz der untersuchten Fragestellungen für die Windbranche und das Interesse der Unternehmen an den Lösungsvorschlägen des EVW-Projektes. Nr. Firma Nr. Firma KWS 2. AREVA Wind 16. Munich Re 3. BKW FMB Energie AG 17. PNE Wind 4. Bosch Rexroth 18. ProSOCON 5. BTC 19. PSI 6. Cmc GmbH 20. PSM 7. Deutsche Windtechnik 21. Reinmetall Technical Publications 8. EnBW 22. Simplements 9. Enercon 23. SoftEnergy 10. FGW 24. TÜV Süd 11. Global Tech 25. VGB 12. GS Weidmüller 13. ImWind 27. wpd windmanager 14. INFAI Tabelle 7: Im Projektbeirat des EVW-Projektes Phase 2 engagierte Unternehmen Gremienarbeit Prinzip bedingt basieren die Ansätze zum Aufbau einer unternehmensübergreifenden Erfahrungsdatenbank, zur Verbesserung der Qualität von Instandhaltungsdaten und zum verstärkten Einsatz von Standartsoftware auf einheitlichen Definitionen zur Datenerfassung und zum Datenaustausch, welche durch Standards und Richtlinien bereitgestellt werden. Um die Entwicklung, Fertigstellung und Verbreitung der notwendigen Richtlinien und Standards voranzutreiben hat sich das EVW-Projektteam intensiv in die Gremienarbeit eingebracht und dabei u.a. maßgeblich die Veröffentlichung der ZEUS und GSP-Richtlinien durch die Arbeitskreise der FGW vorangetrieben Globales-Service-Protokoll (GSP) Das im Rahmen der Technischen Richtlinie 7 Rubrik D3 der FGW definierte Globale-Service-Protokoll (kurz GSP) stellt eine einheitliche Schnittstelle zum Austausch von Instandhaltungsdaten in Form von Instandhaltungsaufträgen und Instandhaltungsberichten zur Verfügung. Nach intensiver und regelmäßiger Arbeit des Arbeitskreis GSP konnte Revision 0 der Richtlinie im Januar 2014 in deutscher und kurze Zeit später auch in englischer Sprache veröffentlich werden. Die EVW-Projektpartner haben sich hierzu intensiv mit der Erarbeitung des GSP beschäftig, im Verlauf des Gremienarbeit wurde so auch die Arbeitskreisleitung durch das Fraunhofer IWES übernommen. Weitere Details zum GSP sind in Kapitel enthalten. Abschlussbericht EVW Phase

141 Zustands-Ereignis-Ursachen-Schlüssel (ZEUS) Darstellung der Der im Rahmen der Technischen Richtlinie 7 Rubrik D2 der FGW definierte Zustands-Ereignis- Ursachen-Schlüssel (kurz ZEUS) dient zur einheitlichen Kategorisierung von Ereignissen an der WEA und daraus resultierenden Zuständen sowie zur Kategorisierung von Instandhaltungsmaßnahmen. Instandhaltungsdaten lassen sich so einheitlich und ohne die Verwendung von Freitexten erfassen. Während der EVW-Projektlaufzeit wurden durch den Arbeitskreis ZEUS zwei Revisionen der Richtlinie erarbeitet und Verabschiedet. Revision 0. wurde zum veröffentlicht, Revision 1. erschien zum und baut auf den Erfahrungen der EVW-Partner bei der Umsetzung von Testanwendungen auf. Die Leitung des Arbeitskreises erfolgte durch die ENERTRAG. Zusätzlich wurde vom Arbeitskreis ZEUS ein Anwendungsleitfaden zur Richtlinie im Entwurf erarbeitet, welcher diesem Bericht als Anlage beiliegt. Gegenwärtig ist geplant, den Anwendungsleitfaden mit Revision 2 der ZEUS-Richtlinie Ende 2015 zu veröffentlichen. Weitere Details zum ZEUS sind in Kapitel enthalten Arbeitskreis Instandhaltungsdokumentation Die Richtlinien GSP, ZEUS und RDS-PP definieren zwar wie sich Instandhaltungsdaten erfassen und austauschen lassen, die Festlegung welche Informationen tatsächlich zu erfassen, zu speichern und Vertragspartnern bereitzustellen sind, erfolgt jedoch nicht. Um die Anforderungen aus Gesetzen, Normen und verbindlichen Richtlinien zusammenzufassen und für die Anwendung in der Windbranche aufzubereiten wurde der Arbeitskreis Instandhaltungsdokumentation durch den Fachausschuss Instandhaltung der FGW ins Leben gerufen. Die konstituierende Sitzung des Arbeitskreises fand im März 2014 statt. Bis zum Ende der Projektlaufzeit im November 2014 hat das Fraunhofer IWES die Arbeit des Arbeitskreises unterstützt. Die Arbeit des AK Instandhaltungsdokumentation ist aus Sicht des EVW-Projektes sehr zu begrüßen und bildet einen weiteren Baustein zur Vereinheitlichung von Instandhaltungsdaten in der Windbranche Reference Designation System for Power Plants (RDS-PP) Das Reference Designation System for Power Plants (kurz RDS-PP ) des VGB dient der einheitlichen Bezeichnung von Kraftwerkskomponenten entsprechend ihrer Funktion im Gesamtsystem. Die im Jahr 2006 durch den VGB zum RDS-PP veröffentliche Anwendungserläuterung für Windkraftwerke (VGB-B 116 D2) hat sich bei der Anwendung in der Windbranche als zu unpräzise und als den Anforderungen der Windbranche sowie den zugrundeliegenden Normen nicht entsprechend herausgestellt, so dass eine Überarbeitung der Anwendungserläuterung erfolgte und diese im Frühjahr 2014 als VGB-S veröffentlicht wurde. Neben vielen weiteren Unternehmen der Windbranche haben sich auch die Projektpartner ENERTRAG, Fraunhofer IWES und IZP Dresden an der Erarbeitung und Validierung der Anwendungsrichtlinie beteiligt und u.a. die für den Aufbau einer unternehmensübergreifenden Datenbank notwendigen Anforderungen an die Kennzeichnungssystematik eingebracht. Weitere Details zum RDS-PP sind in Kapitel enthalten IEA Task 33 Reliability Data Um auch auf europäischer und internationaler Ebene die Vereinheitlichung zuverlässigkeitsrelevanter Daten und deren Auswertungen zu fördern sowie die erzielten RDS-PP, ZEUS und GSP auch über Deutschland hinaus bekannt zu machen und in die Anwendung zu bringen, hat das Fraunhofer IWES zusammen mit internationalen Partner im Jahr 2012 den Task 33 Reliability Data der IEA Wind ins Leben gerufen und die Leitung des Tasks übernommen. Die Mitarbeit am Task 33 der IEA Wind Abschlussbericht EVW Phase

142 Darstellung der durch das Fraunhofer IWES erfolgte zwar im Rahmen des Projektes Offshore~WMEP, durch den engen Austausch zwischen beiden Projekten konnten jedoch auch die des EVW-Projektes in der Gremienarbeit berücksichtigt werden. Ziel ist die Erarbeitung der von Recommended Practices für die Erfassung und Auswertung von Instandhaltungsdaten. Die Erfahrungen aus dem EVW-Projekt fließen hier ein und sollen die weitere Verbreitung der Standards RDS-PP, ZEUS und GSP sowohl national als auch international fördern. Weiter Informationen sind auf der Webseite des Task unter abrufbar Publikationen Im Rahmen der Öffentlichkeitarbeit und Wissensverbreitung wurden in Verbindung mit dem EVW- Projekt diverse Veröffentlichungen für Fach- und populärwissenschaftlichen Zeitschriften erstellt, sowie Buchbeiträge erarbeitet. Veröffentlichungen im Rahmen von Konferenzteilnahmen sind in Kapitel aufgelistet. Beiträge in Zeitschriften 2011: Fachbeitrag in der Zeitschrift Digital Engineering Magazin Ausgabe 06/2011, Zuverlässigkeit und Instandhaltung von Windenergieanlagen - Verfügbarkeit steigern, Kosten senken, Stefan Faulstich et al. (Fraunhofer IWES), ISSN X 2011: Fachbeitrag in Erneuerbare Energien Ausgabe 02/2011, Lebensdauer auf Abruf, Stefan Faulstich et al. (Fraunhofer IWES), ISSN: : Beitrag in der Zeitschrift Ingenieur Spiegel Ausgabe 04/2011, Entwicklung der Windenergienutzung in Deutschland, Philipp Lyding et al. (Fraunhofer IWES), ISSN : Beitrag in der Zeitschrift Ingenieur Spiegel Ausgabe 04/2012, Diversifizierung des Windenergiemarktes für Neuinstallationen, Philipp Lyding et al. (Fraunhofer IWES), ISSN Fachbeitrag in BWE Marktübersicht Spezial 2012 Service, Wartung und Instandhaltung, EVW/OWMEP-Wissensdatenbank: Eine Kennwertebibliothek zur Optimierung von Asset- und Instandhaltungsmanagement, Klaus Pfeiffer et al. (ENERTRAG) 2013: Fachbeitrag in der Zeitschrift Energiewirtschaftliche Tagesfragen et Ausgabe 12/2013, Entwicklung der Performance von Windenergieanlagen, Stefan Faulstich et al. (Fraunhofer IWES) Buchbeiträge 2014: BWE-Praxisbuch Windenergie Betriebsführung, Buchbeitrag Technische Betriebsführung von morgen - Agieren statt Reagieren aus dem EVW-Projektteam vertreten durch Klaus Pfeiffer (ENERTRAG), ISBN: Relevante Pressemitteilungen 2014: Pressemitteilung der FGW vom : Globales-Service- Protokoll (GSP) bringt Transparenz in die Instandhaltung von Windenergieanlagen 2014: Pressemitteilung der FGW vom August 2014: Standardisierte Instandhaltungsdokumentation kommt in der Windbranche an Abschlussbericht EVW Phase

143 Darstellung der Durchgeführte Abschlussarbeiten 2011: Masterarbeit Simulation des Ausfallverhaltens von Windenergieanlagen, erstellt durch Sebastian Pfaffel, eingereicht an der Universität Kassel (Fraunhofer IWES) 2011: Masterarbeit Ökonomische Analyse zuverlässigkeitsrelevanter Informationen von WEA, erstellt durch Oleg Buschin, eingereicht an der Universität Kassel (Fraunhofer IWES) 2014: Masterarbeit Konzipierung und Implementierung einer Applikation zur mobilen Datenerfassung in der Instandhaltung von WEA, erstellt durch Shora Shirzad, eingereicht an der Universität Kassel (Fraunhofer IWES) Vorträge Im Rahmen bzw. in Zusammenhang mit dem EVW-Projekt wurden von den Projektpartnern die in Tabelle 8 dargestellten Vorträge auf Messen, Seminaren und Konferenzen gehalten. Hintergrund ist die Bekanntmachung der Forschungsarbeiten sowie die Werbung weiterer Unternehmen zur Teilnahme am WInD-Pool. Zu einem Teil der aufgelisteten Konferenzen sind auch Veröffentlichungen in Form von Papern entstanden. Diese sind im Abschnitt Publikationen (2.6.3) nicht explizit aufgelistet. Datum Anlass und Ort Titel Partner EWEC Annual Event 2011, Brüssel, Belgien Optimising flow of maintenance information to boost turbine efficiency IWES VDI-Fachtagung Technische Zuverlässigkeit Entwicklung und Betrieb zuverlässiger Produkte, Leonberg Erhöhung der Verfügbarkeit von Windenergieanlagen IWES SKF Wind Farm Management Conference, Barcelona, Spain Establishing a common database for maintenance optimisation IWES WAB Konferenz WINDSTÄRKE 11, Bremerhaven Operational durability on call - Efficient maintenance strategies - Improving reliability and availability IWES BWE-Fachtagung Service, Wartung & Betrieb, Bremen Lebensdauer auf Abruf Effiziente Instandhaltungsstrategien für den Betrieb IWES EERA Workshop O&M, Aalborg, Denmark The IWES O&M database projects Optimzing maintenance through efficient use of experience IWES Sandia 2011 Wind Turbine Reliability Workshop Establishing a common database for turbine failures IWES VDI-Fachkonferenz Instandhaltung von Windenergieanlagen WEA Zuverlässigkeitsorientierte Instandhaltung mittels Datenmanagement und -analyse IWES Wind Power Expo 2011, Zaragoza, Spain Current trends of wind farm maintenance in europe IWES Bureau de coordination énergie éolienne / Koordinierungsstelle Windenergie e.v.. Berlin Optimizing maintenance data management to increase turbine and maintenance strategies efficiency IWES Windpowermonthly Forum O&M, Hamburg Optimizing data structure & storage to boost turbine and maintenance efficiency IWES th Deep Sea Offshore Wind R&D Seminar, Trondheim, Norway Monitoring Offshore Wind Energy Use in Europe IWES VDI-Fachtagung Maintenance of Wind Turbines, Hamburg Reliability-based maintenance - using data management and analysis IWES Abschlussbericht EVW Phase

144 Darstellung der Datum Anlass und Ort Titel Partner nd. ESReDA Seminar on Risk and Reliability for Wind Energy and other Renewable Sources, Glasgow, UK Enabling Multi-Agent-Systems for wind turbine maintenance optimization through a common database IWES BWE-Fachtagung Service, Wartung und Betrieb, Hamburg Schadensstatistiken von Windenergieanlagen IWES SKF Wind Farm Management Conference, Paris, France Maximizing availability and reliability of wind turbines - through a common database IWES Windpower Monthly Forum Onshore Operation and Maintenance,Hamburg Reliability-based maintenance - using data management and analysis IWES VDI Konferenz Schadensanalyse und Werkstoffe in der Windenergietechnik, Bremerhaven Zuverlässigkeitsorientierte Instandhaltung auf Basis einer zentralen Schadensdatenbank IZP Informationslücken schließen und VDI-Fachkonferenz Instandhaltung von Windenergieanlagen, Bremen Instandhaltungsdaten optimieren Standardisiertes Instandhaltungsmanagement als Grundlage für den Windenergie Informations Datenpool WInD-Pool IWES EAWE 8th PhD Seminar on Wind Energy in Europe, Zürich, Schweiz Deployment of Multi-Agent-Systems for optimizing O&M of wind turbine IWES Husum WindEnergy 2012, Husum Benefits from O&M-Data optimization of operation and maintenance IWES Fachtagung BIREA, Betriebsführung und Instandhaltung regenerativer Energieanlagen, Leipzig Standardisierung und Normung im Bereich erneuerbarer Energien IWES BMU-STRATEGIEGESPRÄCHE zur Windenergie; Berlin Erhöhung der Verfügbarkeit von Windenergieanlagen (EVW) IZP Windenergietage NRW, Bad Driburg Schadensstatistik von Windenergieanlagen und präventive Schadensvermeidung IWES DEWEK 2012, Bremen Influence of reliability on operating profit IWES EWEA Annual Event 2013, Wien, Österreich A holistic approach for collection and utilization of O&M data IWES NRW Branchentag, Düsseldorf NRW Branchentag, Düsseldorf GreenPower-Konferenz, Manchester, UK FGW Instandhaltungsrichtlinie TR7 und ihre Konzeption Anforderungen und Nutzen der zuverlässigkeitsorientierten Instandhaltung Getting the most from operational data to reduce O&M costs in the short and long-terms IWES IZP IWES BWE-Seminar Betrieb und Instandhaltung, Hamburg Windenergieanlagen Schadensanalysen und Strategien zur Schadensvermeidung IWES SAP Wind Energy Operator Exchange, Walldorf Improving WT availability through reliability centered maintenance IWES VDI-Fachtagung Instandhaltung, Hamburg FGW Instandhaltungsrichtlinie TR7 Hintergrund, Inhalt, Konsequenzen IWES Abschlussbericht EVW Phase

145 Darstellung der Datum Anlass und Ort Titel Partner AK Innovation&Forschung Windenergie, Düsseldorf Erkenntnisse aus Betriebs- und Schadensdatenbanken für on- und offshore Windenergieanlagen IWES BWE-Seminar Windenergieanlagen Schadensanalysen und Strategien zur Schadensvermeidung, Berlin Windenergieanlage im Betrieb IWES BWE Fachtagung - Service, Instandhaltung und Betrieb von WEA, Hamburg Die Benchmark-Plattform WInD-Pool - Benchmarking und zuverlässigkeitsorientierte Instandhaltung (ZIH) mittels einer gemeinsamen Datenbank IWES WindEnergy Hamburg Standardisierte Instandhaltungsdokumentation: Praktische Anwendung von RDS-PP, ZEUS und GSP in der Windbranche FGW, IWES WIS UserGroup 2014, Rostock Zustands-Ereignis-Ursachen-Schlüssel: ZEUS IZP BWE-Seminar Windenergieanlagen Schadensanalysen und Strategien zur Schadensvermeidung, Berlin Windenergieanlage im Betrieb IWES GreenPower Wind Operator Congress Europe: October, London, UK Benefits of industry wide data pooling - Wind Energy-Information-Data-Pool (WInD-Pool) IWES RAMS 3.-LCC Expertenforum, Dresden Die zentrale Schadensdatenbank WInD-Pool als Basis zur Optimierung von Zuverlässigkeit und Instandhaltung von Windenergieanlagen IWES Windpower Monthly 4th Annual Wind Farm Data Management And Analysis WInD-Pool: A Joint Database for Reliability Analyses IWES Mai 2015 BWE Konferenz Hamburg; Windkraft Service Instandhaltung und Betrieb Fehlervermeidung und Optimierung durch standardisierte Dokumentation als Basis für die Anwendung der RAMS/LCC-Methodik IZP Tabelle 8: Vorträge auf Messen, Seminaren und Konferenzen Abschlussbericht EVW Phase

146 2.6.5 Projektwebseite Darstellung der Ein wichtiges Instrument zur Öffentlichkeitsarbeit bzw. zur Wissensverbreitung ist die Webseite zum EVW-Projekt. Die Projektwebseite aus der ersten Projektphase wurde hierzu zunächst weitergeführt. Im Projektverlauf erfolgten unter Koordination der FGW eine komplette Überarbeitung des Internetauftritts und der Relaunch im Frühjahr Als technische Grundlage wurde hierzu das Content Management System TYPO3 verwendet, wodurch Änderungen an der Webseite für alle Projektpartner einfach durchführbar sind. Abbildung 94: Struktur der EVW-Projektwebseite Inhaltlich umfasst die Webseite eine kurze Beschreibung des Forschungsvorhabens sowie der Ziele der ersten und zweiten Projektphasen. Die umfangreiche Vorstellung des WInD-Pool erfolgt ebenso auf der Webseite wie die Auflistung von Events und Veröffentlichung sowie die Vorstellung der Projektpartner. Wesentliche Dokumente wie die Informationen aus den Projektbeiratssitzungen sind von der Webseite herunterladbar. Abschlussbericht EVW Phase

147 Ausblick 3 Ausblick 3.1 Erreichter Stand Im Kontext einer sich weiterhin schnell entwickelnden Branche sind die im Rahmen des EVW-Projektes Phase 2 erzielten als vorläufig zu betrachten bzw. dienen als Grundlage für weitergehende Praxisentwicklungen. Die durch intensive Gremienarbeit vorangetriebenen Richtlinien ZEUS und GSP sind in den Revisionen 1. bzw. 0. verfügbar und können sowohl in der Praxis als auch in Forschungsprojekten angewendet werden. Im Rahmen der Gremienarbeit soll zudem in naher Zukunft geprüft werden, wie die Richtlinieninhalte den Anwendern näher gebracht werden können, beispielsweise durch die Herausgabe von Anwendungsleitfäden. Auf Basis bisheriger Erfahrungen in der Richtlinienarbeit ist davon auszugehen, dass weitere Revisionen notwendig sein werden. Gleiches gilt für die Anwendungsrichtlinie zum RDS-PP, die derzeit in diversen Unternehmen eingeführt wird. Kapitel 2 enthält hierzu einen detaillierten Ausblick. Der auf den benannten Standards- und Richtlinien aufbauende WInD-Pool ist zum Projektende bereit für den operativen Betrieb und umfasst sowohl Daten aus der ersten EVW-Projektphase und dem Wissenschaftlichen Mess- und Evaluierungsprogramm (WMEP) als auch aktuelle Daten der Projektpartner ENERTRAG und GEO. Gespräche mit verschiedenen Unternehmen und Interessensgruppen der Windbranche habe gezeigt, dass der WInD-Pool auf großes Interesse stößt und es über die Instandhaltung von WEA hinaus vielfältige weitere Anwendungsfelder gibt. Aus diesem Grund haben Fraunhofer IWES und IZP Dresden, unterstützt durch mehrere assoziierte Industriepartner, eine Projektskizze (siehe 3.2) zur Fortführung des WInD-Pool sowie zur Erweiterung der Anwendungsmöglichkeiten beim Fördermittelgeber eingereicht. Am Beispiel der Gefährdungsanalyse für ein Windparkprojekt des Projektpartners ENERTRAG hat sich der Wert systematisch erfasster Daten und der darauf aufbauenden Systemanalysen gezeigt. Der beschriebene Anwendungsfall soll zukünftig auch dritten Unternehmen angeboten werden. Da der WInD- Pool wie beschrieben ein großes Potential für weitere Anwendungen bietet, ist deren Erarbeitung in der Projektskizze WEA.WInD-Pool berücksichtigt. Das in Form verschiedener Module zum Projektende zur Verfügung stehende Test- und Demonstrationssystem wird als Gesamtsystem nicht weiterentwickelt werden. Es konnte gezeigt werden, dass ZEUS, RDS-PP und GSP im Instandhaltungsprozess anwendbar sind. Nun gilt es praxisgerechte Lösungen für den Alltagseinsatz zu schaffen bzw. bestehende Lösungen anzupassen. Ein wichtiger Fokus liegt hier auf der mobilen Datenerfassung. Der im EVW-Projekt entwickelte Demonstrator zur Datenerfassung unter Android wird im Rahmen einer Abschlussarbeit an der Universität Leipzig weiterentwickelt. Lösungen unabhängiger Softwareentwickler, wie das Softwarepaket REGAS von RECONSERV GmbH & Co KG, befinden sich derzeit am Markteintritt und lassen auf eine baldige Verbreitung der beschriebenen Systematik hoffen. Abschlussbericht EVW Phase

148 Ausblick 3.2 Projektskizze WEA.WInD-Pool Zur Fortführung und Erweiterung des WInD-Pool sowie die Erarbeitung von Anwendungsmöglichkeiten über den gesamten Lebenszyklus von WEA, haben Fraunhofer IWES und IZP Dresden die Projektskizze Wertschöpfung durch die Erweiterung der Anwendungsmöglichkeiten des Windenergie-Informations- Daten-Pool (kurz WEA.WInD-Pool) beim Fördermittelgeber eingereicht. Die Projektskizze wird von 7 Unternehmen der Windbranche mitgetragen, welche als assoziierte Partner auch die Finanzierung des Projektes unterstützen wollen. Im skizzierten Projekt sollen wesentliche neue Anwendungsfelder für die Daten des WInD-Pools erschlossen und der weitere Betrieb und Ausbau dieser weltweit einzigartigen Datenbasis sichergestellt werden. Zwar befindet sich der zusammen mit Betreibern/Betriebsführern ins Leben gerufen WInD- Pool derzeit noch im Aufbau, hat aber schon heute das Potential die weltweit umfangreichste Datenbasis an Betriebs- und Instandhaltungsdaten zu werden. Abbildung 95: Nutzen des WInD-Pool über die Lebenszyklusphase einer WEA Gespräche mit Unternehmen der Windbranche haben bekräftigt, dass der WInD-Pool als unternehmensübergreifende Wissensdatenbank auch in weiteren Lebenszyklusphasen von Nutzen sein kann. Von Interesse ist der WInD-Pool dabei u.a. für Projektplaner, Investoren, Versicherungen, Servicedienstleister, Sachverständige, Betreiber & Betriebsführer und Komponentenhersteller. Eben jene Unternehmen wollen sich nun als assoziierte Partner auch an der Finanzierung des Projektes beteiligen. Das übergeordnete Ziel des vorgeschlagenen Vorhabens ist die Senkung der Stromgestehungskosten durch die Bereitstellung statistisch belastbarer Informationen für unternehmerische Entscheidungen in verschiedenen Phasen der Windenergienutzung. Wichtigste Voraussetzung hierzu ist der Ausbau und Betrieb des WInD-Pool, welcher die statistische Grundlage für eine Vielzahl an Anwendungsmöglichkeiten bildet. Insbesondere Betreibern und Betriebsführern wird so ein Zuverlässigkeits- und Performance-Vergleich ermöglicht. In Bezug auf die Zuverlässigkeit von WEA und Komponenten sollen im Rahmen des Vorhabens umfangreiche Informationen in den WInD-Pool eingepflegt werden, um u.a. ein Frühwarnsystem zu häufigen Schäden aufzubauen oder die Entwicklung von Design-Optimierungen bzw. Retrofit- Paketen zu unterstützen. Die des vorgeschlagenen Vorhabens sollen außerdem bei der Pro- Abschlussbericht EVW Phase