Fallbeispiel: Einführung eines Optimierungssystems

Situation:

Bei einem Kunden, der ein System von Pumpspeicherkraftwerken betreibt, wird die Leittechnikebene erneuert.

In dem neuen System wird auch eine Simulationsmechanik hinterlegt, die auf Basis eines mathematisch-physikalischen Modells für eine gegebene Abgabe- oder Aufnahmeleistung diejenige Konfiguration der einzelnen Kraftwerkseinheiten errechnen soll, die am wirtschaftlichsten arbeitet. Diese wird den Bedienern der Anlage als Vorschlag an die Hand gegeben; über dessen Umsetzung entscheidet jedoch der Bediener eigenverantwortlich.

Ablauf der Optimierung:

Über einen elektronischen Datenaustausch wird von außen die sog. „Leistungsvorhaltung“ in das Leitsystem eingegeben. Diese repräsentiert diejenige elektrische Leistung, die die Gesamtanlage dem Kunden zur Verfügung stellen muß. Über ihre Ausnutzung entscheidet der Kunde über weitere Regelungsprozesse.

Aus dem aktuellen Stand der Speicher, den Maschinendaten sowie der hinterlegten Maschinenstellung (zu-/abgeschaltet, verfügbar, in Wartung etc.) errechnet die Simulation die für diese Situation optimale Konfiguration. Zielgröße der Optimierung ist der Wirkungsgrad, also die Konfiguration, die für die geforderte elektrische Leistung den geringsten Wasseraufwand aufweist.

Theoretisch ist der Optimierungsalgorithmus in der Lage, den besten Wirkungsgrad nachhaltig einzustellen.

Allerdings gibt es einige systembedingte Störgrößen bzw. Unschärfen:

• Die Parameter der verlustbehafteten Betriebsmittel (Stollen, Schieber etc.) sind empirisch ermittelt worden, ggf. aber noch abweichend von den realen Bedingungen.
• Die Parameter der Optimierung (Gewichtung der Maschinen, angenommene Wirkungsgradkurven, Regelverhalten) sind rechnerisch erfaßt, aber mit Toleranzen behaftet.
• Äußere Einflüsse wie etwa Schneeschmelzen und variable natürliche Zuflüsse sind nicht exakt vorhersehbar bzw. nicht direkt meßbar.
• Je nach aktueller Situation kann es erforderlich werden, hinsichtlich anderer Größen zu optimieren, die die Automatik nicht von sich aus erkennen und berücksichtigen kann.

Ablauf im Betrieb:

Die zentrale Warte ist besetzt mit zwei bis drei Bedienern je Schicht, die die Konfiguration der Maschinen und den Gesamtbetrieb des Kraftwerkssystems überwachen.

Erfolgt die Eingabe einer neuen Anforderung (von außen) wird diese zunächst in einen sog. „Maschinenvorschlag“ umgesetzt, also eine Darstellung der vom Simulationsalgorithmus bestimmten optimalen Konfiguration.

Diese kann von den Bedienern akzeptiert und direkt umgesetzt werden. Allerdings steht es den Bedienern auch frei, Anpassungen durchzuführen, wenn sie aus Erfahrung wissen, daß eine andere Konfiguration erforderlich oder sinnvoll ist.

Dies kann im normalen Betrieb vorkommen, wird aber auf jeden Fall notwendig sein, wenn Sonderfälle wie z.B. die bereits genannte Schneeschmelze auftreten.

Vorgenommene Änderungen werden zusammen mit den externen Anforderungen sowie den Zustandsdaten der Leittechnik automatisch protokolliert (Betriebstagebuch)

Anforderungen an den Prozeß außerhalb der Leittechnik:

Zur mittelfristigen Steuerung des Betriebs werden die Betriebsdaten in regelmäßigen Abständen durchgesehen und ausgewertet.

Hierbei werden sich zwischen den vom Algorithmus bestimmten Konfigurationen bzw. den antizipierten Betriebsdaten, und denen, die tatsächlich gefahren wurden, Diskrepanzen ergeben.

Diese Diskrepanzen sollten konkret ausgewertet werden, um Antworten auf folgende Fragenkomplexe zu finden:

• An welchen Stellen sind zur Weiterentwicklung des Simulationsalgorithmus Anpassungen der systeminternen Parameter und Stammdaten erforderlich?
• Wo im äußeren Prozeß sind eventuell Anpassungen oder Verfeinerungen erforderlich?

Beide Teile dienen als eine Feedbackschleife, mit der sich die Leittechnik mittelfristig in einen dauerhaft stabilen Betriebsprozeß begeben soll.

Dabei dient der erste Teil im Wesentlichen einer rein technischen Feinabstimmung eines komplexen Automatisierungssystems.

Letzteres berührt jedoch tief persönliche Aspekte, da eine Art Aufzeichnung der Bediener stattfindet:

Um den Prozeß zu hinterfragen ist es notwendig zu erfahren, aus welchen Beweggründen und Überlegungen die Bediener von der berechneten Konfiguration abgewichen sind.

Dies erfordert zum einen eine sehr sensibel formulierte Anforderung.

Zum anderen darf auf keinen Fall der Eindruck entstehen, die Bediener würden in Frage gestellt und überwacht, dient diese Erhebung doch dem gemeinsamen Lerneffekt und der Verbesserung der gemeinsamen Unternehmung.

Mögliche Bedenken sind hier:

• Befürchtete „Wegrationalisierung“ von weiteren Arbeitsplätzen durch Stärkung einer automatischen Funktion
• Wahrnehmung einer Art von „Gängelung“ durch eine Automatik und/oder neue Prozeßabläufe
• Gefühlter Rechtfertigungsdruck gegenüber dem Arbeitgeber/Vorgesetzten
• Möglicherweise folgender Verlust der Bereitschaft zur souveränen und sachkundigen Entscheidung der Bediener („Laß das System mal machen. Dann muß ich mich nicht rechtfertigen.“)
• Damit Verlust der Betriebsqualität in großem Umfange (-> potentieller Kollateralschaden des Projektes durch Einführung einer automatischen Berechnung)

Möglichkeiten zur Lösung des Problems:

Grundlage allen Handelns ist die Prämisse, daß die Dokumentation von Entscheidungen aus eigenem Antrieb zur persönlichen Weiterentwicklung erfolgt. Wir gehen also davon aus, daß die Bediener hier auch ihrem eigenen Willen zur Weiterentwicklung folgen.

Ferner muß der Aufwand zur Erfassung dieser Informationen möglichst gering sein, damit dies die Akzeptanz nicht weiter einschränkt.

Im Workshop beim PM-Camp in Dornbirn wurde folgendes Ergebnis erzielt:

Um dem Änderungsprozeß eine realistische Chance einzuräumen, ist es notwendig, die Bediener in seine Realisierung aktiv einzubinden. Die Bediener müssen selbstmotiviert  am Lösungsprozeß teilnehmen. (oder vielmehr „teilgeben“)

Andere Maßnahmen könnten dem Projekt resp. dem Betriebsumfeld Schaden zufügen.

Erforderlich ist es auch, den potentiellen Nutzen klar herauszustellen (hier „sachlicher Nutzen“)

• Identifikation der tatsächlichen Zusammenhänge bei Nichterreichung von KPI oder anderen Meßgrößen
• Aufzeigen der Notwendigkeit manueller Eingriffe in signifikantem Rahmen und Quantifizierung dieses Rahmens

Möglicher Zusatznutzen auf Metaebene („gefühlter Nutzen“)

• Damit Entlastung der Bediener und
• Entspannung hinsichtlich der Bedenken einer „Wegrationalisierung“ (s.o.)
• Quantifizierung der Manuellen Eingriffe auch zur Sicherung der Aufgaben der Bediener

Der einheitlich bevorzugte Ansatz ist die Einladung zu einem gemeinsamen Workshop, der von einem externen und/oder unbeteiligten Berater moderiert wird.

Dabei sollen die Bediener an das Thema in der Art herangeführt werden, daß sie die Anforderungen hinsichtlich der systematischen Anpassungen sachlich verstehen, einen eigenen Nutzen erkennen und aktiv zur Lösungsfindung beitragen.

Im Nachgang würde diese Partizipation dafür sorgen, daß die Durchführung einer Dokumentation konsequenter und ausführlicher stattfindet.

Das wahrscheinlichste Ergebnis dieses Workshops könnte die Idee eines Tagebuch- oder Logeintrages für Abweichungen vom Maschinenvorschlag sein.

Dieser könnte folgende Optionen beinhalten:

• Tatsächlicher Eintrag in ein Offline-Betriebstagebuch im Freitext
  Pro: Ausführliche Daten für Auswertung
  Contra: Interpretationsbedürftig, da individuell; großer Aufwand; möglicherweise größere Hemmschwelle
• Beantwortung einer kurzen Checkliste im Leitsystem durch Ankreuzen typischer Betriebssituationen (diese sind historisch bekannt und qualitativ dokumentiert)
  Pro: Schnell auszufüllen; geringe Hemmschwelle; Leichter auszuwerten
  Contra: Zusätzliche Implementierung im Leitsystem; ggf. weitere Rücksprache erforderlich

Fazit:

Zur Erlangung eines fundierten und brauchbaren Nutzfeedbacks im beschriebenen Fallbeispiel ist es nicht nur angezeigt, sondern zwingend notwendig, daß dieses freiwillig und selbstmotiviert gegeben wird. Speziell die Interaktion mit allen beteiligten Personen bringt hier die Motivation zur Verbesserung eines vorgezeichneten Prozesses.

Vorgeschriebene oder anderweitig fremdgesteuerte Dokumentation werden voraussichtlich keinen Erfolg bringen und dem Projekt möglicherweise schaden.
(Vgl. auch Projektinszenator.de, 1. Schritt „Schäden / Nutzen“)