AIRSPOT
Wind Intelligence
Diese Analyse enthält interaktive Diagramme und ein zweispaltiges Layout, das auf Mobilgeräten nicht optimal dargestellt werden kann.
Bitte öffne den Link auf einem Desktop-Computer oder iPad/Tablet im Querformat.
Kurz vorweg — wie bin ich überhaupt hier gelandet:
Ich habe mich in der letzten Woche intensiv mit der Frage beschäftigt, wie viel Betriebszeit wir durch Wind verlieren — und ob wir daran etwas ändern können. Dafür habe ich mich durch Wetterdatenbanken weltweit gewühlt: DWD Deutschland, Open-Meteo, NOAA, Environment Canada, australische BOM-Stationen. Das Problem: Fast alle liefern nur 10-Minuten- oder Stunden-Durchschnitte. Viel zu grob für unsere 5-Sekunden-Alarmtimer.
Dann bin ich auf das Iowa Environmental Mesonet gestoßen — 900+ US-Flughäfen, 1-Minuten-Daten mit 5-Sekunden-Böenspitzen. Ich habe einen Scraper gebaut, 26 Jahre Daten von fünf Flughäfen runtergeladen, eine Replik unserer CX8290-Zustandsmaschine programmiert und die Daten durchsimuliert.
Dabei ist mir etwas aufgefallen, das ich euch zeigen will: Die Recovery-Timer — also wie lange die Maschine nach einem Wind-Event wartet, bevor sie zurück in den Betrieb geht — sind ein riesiger Hebel. Und genau das seht ihr jetzt in den Daten.
Im schlimmsten Windmonat sieht es so aus: Eine CX8290 mit Standard-Einstellungen verliert einen erheblichen Teil ihrer Betriebszeit. Jede Stunde ohne BETRIEB-Modus heißt verlorene Werbefläche — und verlorener Umsatz.
Die Maschine kennt drei Zustände:
Die Frage: Wie viel Betriebszeit geht verloren — und können wir das optimieren?
Die Analyse basiert auf echten Flughafendaten: 1-Minuten-Messungen mit 5-Sekunden-Böenspitzen vom Chicago O'Hare International Airport — hochgerechnet auf 25m Masthöhe (Power-Law-Profil, alpha=0.25).
Das ist die einzige frei verfügbare Datenquelle, die ich mit dieser Auflösung gefunden habe: 1-Minuten-Intervalle plus die 5-Sekunden-Spitzenböe pro Intervall. Damit lassen sich unsere Maschinenzyklen realistisch simulieren.
Warum diese Präzision entscheidend ist: 10-Minuten-Durchschnitte verschleiern kurze Böen, die Alarme auslösen. Erst mit 1-Minuten-Daten sieht man die einzelnen Wind-Events — und versteht, warum die Maschine reagiert.
Mit unseren eigenen Sensoren an den Maschinen könnten wir sogar bis zu 10ms Auflösung erreichen — und damit noch präzisere Simulationen und Optimierungen fahren.
Rechts seht ihr ein einzelnes Wind-Event: Böe überschreitet 45 km/h → Alarm → Abschaltung bei 54 km/h → 30-Minuten-Recovery → zurück in Betrieb.
Aktuell hat die CX8290 zwei Recovery-Timer, die nach einem Wind-Event bestimmen, wann die Maschine wieder hochfährt:
Diese Zeiten sind konservativ gewählt — und das ist gut für die Sicherheit. Aber: Bei einem kurzen Böenereignis (z.B. 2 Minuten über 45 km/h, dann wieder Ruhe) wartet die Maschine trotzdem die vollen 30 Minuten. Das ist verlorene Betriebszeit.
Was passiert, wenn wir diese Timer verkürzen?
Ich habe 300 verschiedene Timer-Kombinationen durchsimuliert (Recovery-45: von 1 bis 30 Minuten, Recovery-54: von 1 bis 10 Minuten) und für jede Kombination zwei Werte gemessen:
Wie liest man die Pareto-Kurve:
Links unten: konservativ (wenig Zyklen, weniger Betrieb). Rechts oben: aggressiv (viele Zyklen, maximaler Betrieb). Der Knee-Punkt zeigt, wo das Kosten-Nutzen-Verhältnis am besten ist.
Ich weiß, dass die erste Frage sein wird: Geht das überhaupt durch den TÜV? Ich glaube ja — und zwar so:
Die Sicherheitsparameter (Windgrenzen + Alarm-Timer) bleiben fest im PLC — ein Programm, eine TÜV-Abnahme. Nur die Recovery-Messzeiten werden remote gesetzt.
Zusätzlicher Fallback: Alle 24h setzen sich die Recovery-Timer automatisch auf die Standardwerte (30min / 10min) zurück, falls der Remote-Controller sie nicht aktiv bestätigt. Bei Verbindungsverlust fällt die Maschine also immer in den sicheren Modus zurück.
Hier wird's spannend: Mit Machine Learning könnten wir den Winden-Verschleiß prognostizieren — basierend auf Zyklenanzahl, Windintensität und Dauer.
Statt fixer Einstellungen würde jede Maschine ihre optimalen Parameter lernen — dynamische Anpassung je nach Tageszeit, Saison und Standort.
Die drei Punkte auf der Kurve zeigen, wo verschiedene Konfigurationen auf dem Pareto-Spektrum landen.
Bei der Analyse der Recovery-Timer ist mir aufgefallen, dass sich daraus ein interessantes Geschäftsmodell ableiten ließe — drei Stufen, die unterschiedliche Kundenbedürfnisse bedienen:
Technisch umsetzbar mit einem einzigen TÜV-zertifizierten PLC-Programm — die Sicherheitsgrenzen bleiben hardcoded, nur die Recovery-Messzeiten werden per MQTT remote gesetzt (Details siehe oben).
Das ist erstmal nur ein Vorschlag — aber die Daten zeigen, dass hier echtes Potenzial steckt. Was meint ihr?
Hier könnt ihr die Timer selbst einstellen und die Auswirkungen in Echtzeit sehen.